Views: 6,919,707 Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 04-26-24 01:26 AM
Guest:

Main - Posts by andlabs


andlabs
Posted on 10-05-17 07:46 PM, in libui notes/ideas for improvement (rev. 2 of 10-05-17 07:47 PM) Link | #373
Newcomer
Normal user

Level: 4

Posts: 1/2
EXP: 138
Next: 141

Since: 10-05-17

Last post: 2391 days ago
Last view: 2380 days ago
Posted by StapleButter
So I used libui and botched it to fit my needs...


Functions that return strings

As they are, they allocate the string on heap and return a pointer. You get to do cool one-liners, but you need to remember to free the string, and it's not so efficient.

Should change those to use stack-allocated string buffers where possible.




On Windows I need to take out a UTF-16 string and convert it to UTF-8, so allocation is going to happen anyway.

This is more do-able on the other platforms, of course.


uiArea handler

(why does this use a handler struct instead of hooking individual event handlers?)



In the event of having multiple Areas that share the same set of events. Think of it as a way of creating your own controls without extending libui.


The handler struct must remain accessible to libui throughout the uiArea's lifetime. Allocating it on stack can be a bad idea, esp. for secondary windows.

(solutions: copy the struct to an internal buffer, for example in the uiArea struct. or use individual handlers.)



I could locally copy it.


Sizing

Under GTK, it is impossible to resize a window smaller than its original size.



Your initial window size is not big enough in this case, because it's GTK+ that limits the size on libui's behalf. Of note is that GTK+ tabs ("notebooks") request enough space for the largest tab page at all times, even if that page isn't the active one. You'll have to talk to the GTK+ team about that. Also note that the minimum size of controls is also theme-dependent.

* [Win/GTK] file dialogs: added filter support, added extra parameter for setting starting dir (not supported yet)

I've wanted to do the filtering, but in one of the OSs if you specify an extension filter in a save dialog, you can't override it. I forget if there were other issues.

As for the starting directory, I forget if the OSs take care of that themselves, and if so, which OSs do (or what I would need to do to enable it if not).

* [Win/GTK] uiArea: added small API for creating and drawing bitmaps

This is in the works as part of the uiTable API. Not sure how it will suit melonDS though...

* [Win/GTK] uiArea: botched keyboard input. only getting raw scancodes

This is deliberate; I wanted uiArea key events to be keyboard layout-independent. This decision is showing its flaws, but I'm not sure yet what I'll do about it. Also note that OS X uses its own scancode list for all keyboards.

* [GTK] uiWindow/GTK: fix window sizing to take the menubar into account. kind of a hack tho.

I thought I took care of this already, but it's probably a TODO. What hack did you do?

* [Win/GTK] uiWindow: add handlers for getting/losing focus and file dragdrop (limited to one file)

What do you mean by getting or losing focus? And for file drag and drop, I've wanted to put that in both uiArea and uiTable as an extra option and as an API, but that was a distant goal. Not sure about doing it to uiWindow...

* [Win/GTK] uiControl: add uiControlSetFocus()

What does this do?

* [GTK] uiArea/GTK: make uiAreaQueueRedrawAll() thread-safe

All libui functions except uiQueueMain() are not thread-safe (in fact, that's the whole point of uiQueueMain()). What did you do for this function? I wonder if it's the right thing to do in the first place...

optimize uiBox sizing under Windows. and/or add grid container (would be better for the input dialog as the sheer amount of boxes lags it) there is already uiGrid but it needs optimization too


Try disabling the WM_CTLCOLOR stuff in windows/parent.cpp or windows/container.cpp (I forget now where it is at present) and seeing if that is the real problem. Other people say it is, but a correct fix that still looks good (as removing that code would make tabs look bad) would require a(nother) major rearchitecture of libui's control hierarchy structure...

If it turns out the containers are indeed slow, I can try switching back to the DeferSetWindowPos() system, but I forget if I'm already using that...

andlabs
Posted on 10-08-17 07:24 PM, in libui notes/ideas for improvement Link | #389
Newcomer
Normal user

Level: 4

Posts: 2/2
EXP: 138
Next: 141

Since: 10-05-17

Last post: 2391 days ago
Last view: 2380 days ago
Posted by StapleButter
I'd have to know more about this, but the name uiTable implies that it wouldn't really fit melonDS's goals.
The plan for uiImage or uiDrawImage (I forget what it's called) is that it stores a bitmap image of a given point size that's backed by one or more representations. Each representation must have the same aspect ratio, but may have different pixel dimensions. libui will automatically pick the best image representation for the target device (so images will scale properly with DPI changes).

Nah, I meant that libui comes with a whole system for detecting 'good' keys and modifiers and all that. Which is nice if you want to implement text entry I guess.

In the case of melonDS, I only need to know when a given key is pressed, and to tell that key apart from other keys, regardless of what it is. (think Left Ctrl vs Right Ctrl)
Actually libui's system is *bad* for text editing, because it's entirely positional. I plan on making a text editing API that integrates tightly with the system. I'm still not sure how your request isn't satisfied by the current API; you just need to determine which of Key, ExtKey, or Modifier is nonzero (in that order), interpret that key, and use Up to see if it's pressed or released. I am currently swallowing knowledge of whether a left or right modifier key is pressed; not sure why I did that or if I should continue to do that...

The issue under GTK is that the menubar is part of the client area, which is inconsistent with Windows.

The original hack was calling gtk_widget_set_size_request() on the window's childHolderWidget. While it sized the client area properly, it also set that as a minimum size.

The final hack kicks in after the window is shown: the final menubar height is retrieved and the window height is adjusted accordingly.
In that case, I would need to subclass some container and implement get_preferreed_width() and get_preferred_height() and call queue_resize() to do the size change. I'm not sure how well this will work the first time or subsequent times...


Under Windows, I need to explicitly give focus to my uiArea or it won't receive key events until it's clicked. I need to do so when creating the window, and when it gets focus (is brought to foreground) after having lost it.

So I added event hooks to detect that. uiControlSetFocus() gives keyboard focus to a particular control.
I can add keyboard focus functions, yes. (On Windows a control has to explicitly request keyboard focus.)

It is called in a g_idle_add() callback if the calling thread isn't the GUI thread.

In melonDS, the emulator loop runs in a separate thread, and that thread needs a way to signal the UI to refresh itself. With GTK, doing it directly caused random freezes.
Then just use uiQueueMain() on all platforms; that's what it's for =P


Main - Posts by andlabs

Page rendered in 0.030 seconds. (2048KB of memory used)
MySQL - queries: 22, rows: 67/67, time: 0.012 seconds.
 [powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.