On 5/8/2014 4:35 PM, Ben Boeckel via Digitalmars-d-announce wrote:
> On Thu, May 08, 2014 at 15:41:57 -0400, Nick Sabalausky via Digitalmars-d-announce wrote:
>> Or better yet, don't. Steam's UI is terrible. Clicking search
>> suggestions often does nothing, the search result paging is goofy as
>> hell and very impractical, the whole thing's absurdly sluggish, in
>> general ignores any and all system settings, menu dropdowns open upon
>> hover instead of click, and, oh yea, my trackpad's scrolling gestures
>> don't even fucking work on it (they work fine on nearly anything else).
>>
>> That's all just off the top of my head. From what I've seen of Tk so
>> far, Steam would have been *far* better if it had used it instead of
>> going to the bother of reinventing everything really, really badly.
>> (Well, at least Steam isn't all-green anymore like it used to be :/ )
>
> IIRC, Steam is a Java beast, so I wouldn't go off and blame Qt/Gtk for
> that.
>
> --Ben
>

I wasn't trying to blame Qt/Gtk (actually, I kinda like Qt stuff - I've heard it's not technically native UI, but hell if I can actually tell the difference. They've done a damn fine job.)

I was just saying Steam likely would have been better had they used something more sensible like Tk instead of going off rolling their own GUI. Qt probably would have work out alright, too. Not to say that Tk/Qt would have solved all of Steam's problems, but I imagine it would've likely been at least an improvement *even* if Tk isn't intended for non-simplistic stuff. A lot of that non-simple stuff isn't really a good idea anyway.

Am 08.05.2014 21:41, schrieb Nick Sabalausky:
> (...)my trackpad's scrolling gestures
> don't even fucking work on it (they work fine on nearly anything else).
>

To be fair, some time ago I've had the joy to try and properly support scrolling gestures properly for my UI framework and I wound up naming the window class of my windows "OperaWindowClass", because that triggers a special case path in the touchpad driver, which actually sends useful window messages. I didn't find another way to get useful data. The whole (Synaptics) driver is obviously nothing but a crapload of special case junk to make the most popular applications and controls work, because the people involved obviously don't manage to develop a standard API for pixel perfect scrolling.

On 5/8/2014 4:51 PM, Sönke Ludwig wrote:
> Am 08.05.2014 21:41, schrieb Nick Sabalausky:
>> (...)my trackpad's scrolling gestures
>> don't even fucking work on it (they work fine on nearly anything else).
>>
>
> To be fair, some time ago I've had the joy to try and properly support
> scrolling gestures properly for my UI framework and I wound up naming
> the window class of my windows "OperaWindowClass", because that triggers
> a special case path in the touchpad driver, which actually sends useful
> window messages. I didn't find another way to get useful data. The whole
> (Synaptics) driver is obviously nothing but a crapload of special case
> junk to make the most popular applications and controls work, because
> the people involved obviously don't manage to develop a standard API for
> pixel perfect scrolling.

Hmm, that may be so. I've yet to find one piece of OEM software that isn't (at best) barely-functional garbage. And I just noticed it apparently doesn't work in Tk even with its native controls, bizarrely enough. I honestly never would have even imagined that this stuff would actually manage to fail on native controls. It just seemed obvious that if there was anything *at all* it would work with, it would be native controls. What a mess.

OTOH, as little respect as I have for OEM software, I wouldn't be surprised if their hand is somewhat forced. If they'd done it by providing an API, nobody would bother to use the API. The only right way would be to integrate with existing OS support, but if the OS doesn't already provide that (I wouldn't know whether it does), then nothing's going to get companies like MS, Apple or likely even Canonical to actually give enough of a rat's ass to pull attention away from their own internal politics and agendas. Can't let nicely working user-facing features get in the way of corporate agendas and red tape, can they? ;)

On 08/05/14 22:43, Nick Sabalausky wrote:

> I wasn't trying to blame Qt/Gtk (actually, I kinda like Qt stuff - I've
> heard it's not technically native UI, but hell if I can actually tell
> the difference. They've done a damn fine job.)

I think it's quite easy to tell the difference, on OS X. But that might be a problem with the actual application, that doesn't follow OS X conventions, and not Qt itself.

-- 
/Jacob Carlborg

On Thursday, 8 May 2014 at 20:51:17 UTC, Sönke Ludwig wrote:
> Am 08.05.2014 21:41, schrieb Nick Sabalausky:
>> (...)my trackpad's scrolling gestures
>> don't even fucking work on it (they work fine on nearly anything else).
>>
>
> To be fair, some time ago I've had the joy to try and properly support scrolling gestures properly for my UI framework and I wound up naming the window class of my windows "OperaWindowClass", because that triggers a special case path in the touchpad driver, which actually sends useful window messages. I didn't find another way to get useful data. The whole (Synaptics) driver is obviously nothing but a crapload of special case junk to make the most popular applications and controls work, because the people involved obviously don't manage to develop a standard API for pixel perfect scrolling.

Now that was a surprise! I just could not understand why I
receive WM_MOUSEWHEEL only with 120 as Delta, but Internet
Explorer receives fine grained (ex. 24). Seting the window class
name as you said, 'solves' indeed the problem!

There are new deb packages for "TkD" v1.0.3 beta, available at <http://d-apt.sourceforge.net/>

To install:
$ sudo apt-get install libtkd-dev libtkd-doc

To compile the TkD example (static linking):
$ dmd `pkg-config --cflags --libs tkd-static` -J/usr/share/libtkd-doc/example/media/ /usr/share/libtkd-doc/example/example.d

To compile the TkD example (shared linking):
$ dmd -release `pkg-config --cflags --libs tkd` -J/usr/share/libtkd-doc/example/media/ /usr/share/libtkd-doc/example/example.d

Regards,
-- 
Jordi Sayol

On Saturday, 10 May 2014 at 17:44:53 UTC, Jordi Sayol via Digitalmars-d-announce wrote:
>
> There are new deb packages for "TkD" v1.0.3 beta, available at <http://d-apt.sourceforge.net/>
>
> To install:
> $ sudo apt-get install libtkd-dev libtkd-doc
>
> To compile the TkD example (static linking):
> $ dmd `pkg-config --cflags --libs tkd-static` -J/usr/share/libtkd-doc/example/media/ /usr/share/libtkd-doc/example/example.d
>
> To compile the TkD example (shared linking):
> $ dmd -release `pkg-config --cflags --libs tkd` -J/usr/share/libtkd-doc/example/media/ /usr/share/libtkd-doc/example/example.d
>
> Regards,

Very nice, thanks for your hard work in doing this. Let's see if people start to use it. :)

On Thursday, 8 May 2014 at 04:46:48 UTC, John wrote:
> How is the performance when compared to other GUIs like Qt or Gtk? For example, in one application, I need to dynamically create several hundred of controls at runtime.

BTW, what's your use case? Nested tabbed dialog? After creation it should also resize fast, which can get problematic too.

On Sunday, 4 May 2014 at 16:18:53 UTC, Gary Willoughby wrote:
> https://github.com/nomad-software/tkd

https://github.com/nomad-software/tkd/blob/master/source/tkd/element/element.d
Since you allocate CommandArgs in C heap, its content is invisible to GC and will be freed - uniqueData and callback.

On Sunday, 11 May 2014 at 10:16:35 UTC, Kagamin wrote:
> https://github.com/nomad-software/tkd/blob/master/source/tkd/element/element.d
> Since you allocate CommandArgs in C heap, its content is invisible to GC and will be freed - uniqueData and callback.

Can you clarify what you mean here? Are you asserting i am cleaning up or i need to somewhere?