On 5/21/13, Kiith-Sa <kiithsacmp@gmail.com> wrote:
> H3r3tic had a more advanced GUI framework (still not native),
> hybrid, which IMO has a far better API than any framework I've
> seen, but I never found the source,
> only documentation somewhere on his (unmaintained) site.

It's here though, hidden in another project:

https://bitbucket.org/h3r3tic/boxen/src/76f3fab1b889/src/xf/hybrid?at=default

On Tuesday, 21 May 2013 at 00:05:21 UTC, Diggory wrote:
> On Monday, 20 May 2013 at 23:40:34 UTC, Andrej Mitrovic wrote:
>> On 5/21/13, Adam Wilson <flyboynw@gmail.com> wrote:
>>> Sub-pixel font hinting. Almost no games use this, and almost every OS
>>> toolkit does.
>>
>> There used to be a nice article about font rendering in OpenGL
>> (methinks) here: http://h3.gd/dmedia/?n=Tutorials.TextRendering1
>>
>> But the link is dead. Most h3r3tic links are dead, not even
>> archive.org has them.
>
> Generally the idea is to pack the characters into a texture and then render from that - it's very fast as you don't have to switch textures which is relatively slow. There are a few different ways of representing the characters (for large text signed distance maps seem to be currently the state of the art) while for small text a simple single channel alpha map is good and fast.
>
> TBH the rendering itself is fairly simple, the hard part is the layout, glyph conversion and kerning. It seems like the new std.uni module actually does some of the glyph conversion which is nice.
>
> Another technique that might be worth looking into is simply getting the OS to render the text as it will be displayed to a texture and then it's just a case of blitting that to the screen. With some caching that could be efficient enough, most gui text does not change very often, otherwise you wouldn't have time to read it...

The code I linked to takes care of glyph positioning/kerning/etc; although I didn't test it with e.g. asian languages, and there might be bugs to work out there.

On 21/05/13 08:49, Adam Wilson wrote:
>
> I'd be willing to lead the project, I'm just not sure I am the right
> person to do so. I have a vision, and the skeleton of a design, but no
> code. I am willing, but my ability is a question mark...
>

I'd volunteer to be a foot soldier on this project as I'd like D to have a useful GUI capability.  At the moment, my experience of GUI programming is at the user of the API end of the spectrum (mostly using PyGTK to write GUI wrappers for command line programs to make my life easier) but I think I'm a quick learner.  Also as a GUI API user I have some idea of the sorts of thing that make a good API.

If D had a usable GUI API I would port at least one of my current PyGTK programs to D as it would benefit from better number crunching capability than Python possesses.

So, if this gets up, give me a call.
Peter

On Mon, 20 May 2013 15:54:10 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:
> 
> Very few actual users care about changing the behavior of the widgets. Most people who want to change them just want to skin them.
> 

One standard deviation is all that ever matters. Everyone else can and should just go fuck off. It's their own goddamn fault anyway for being such a bunch of unreasonable jackasses. Fuck 'em, nobody cares about them anyway, especially since we all know perfectly well they're just a bunch of fat unshowered virgin slobs living in their parent's basement and jerking to "7 of 9".



...Right?



Or, of course, we could just go with the classic favorite: "It's just business."

On Mon, 20 May 2013 15:49:48 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Mon, 20 May 2013 14:47:47 -0700, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> >
> > So to actually do it, I think we need:
> >
> > 1) A "core" for a GUI library written in D that people can start hacking on (meaning you can create windows, and draw in a pixel buffer, capture device input, all platform-independent), and
> >
> > 2) Solid leadership.
> >
> > I'd say #2 is more important than #1, because #1 is something many people can do, and #2 is the really hard bit.
> 
> #2 is critical. #1 is just technical leg-work.
> 
> #2 is tough to find, and to be honest, I don't know that anyone here could say that they have the technical chops to make it happen. I mean how many of us actually do GUI coding every day? I know I do, but I don't think that is enough to qualify one as a leader. We also need a vision and developer commitment.
> 
> I'd be willing to lead the project, I'm just not sure I am the right person to do so. I have a vision, and the skeleton of a design, but no code. I am willing, but my ability is a question mark...
> 

If only vision and willingness weren't the easy, plentiful parts :(  Believe me, I'm in the same boat.

On Mon, 20 May 2013 18:12:20 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 15:49:48 -0700
> "Adam Wilson" <flyboynw@gmail.com> wrote:
>
>> On Mon, 20 May 2013 14:47:47 -0700, Andrej Mitrovic
>> <andrej.mitrovich@gmail.com> wrote:
>> >
>> > So to actually do it, I think we need:
>> >
>> > 1) A "core" for a GUI library written in D that people can start
>> > hacking on (meaning you can create windows, and draw in a pixel
>> > buffer, capture device input, all platform-independent), and
>> >
>> > 2) Solid leadership.
>> >
>> > I'd say #2 is more important than #1, because #1 is something many
>> > people can do, and #2 is the really hard bit.
>>
>> #2 is critical. #1 is just technical leg-work.
>>
>> #2 is tough to find, and to be honest, I don't know that anyone here
>> could say that they have the technical chops to make it happen. I
>> mean how many of us actually do GUI coding every day? I know I do,
>> but I don't think that is enough to qualify one as a leader. We also
>> need a vision and developer commitment.
>>
>> I'd be willing to lead the project, I'm just not sure I am the right
>> person to do so. I have a vision, and the skeleton of a design, but
>> no code. I am willing, but my ability is a question mark...
>>
>
> If only vision and willingness weren't the easy, plentiful
> parts :(  Believe me, I'm in the same boat.
>

Hehe. Sad but true. Why do you think I am hesitant. :-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Mon, 20 May 2013 18:04:10 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 15:54:10 -0700
> "Adam Wilson" <flyboynw@gmail.com> wrote:
>>
>> Very few actual users care about changing the behavior of the
>> widgets. Most people who want to change them just want to skin them.
>>
>
> One standard deviation is all that ever matters. Everyone else can and
> should just go fuck off. It's their own goddamn fault anyway for being
> such a bunch of unreasonable jackasses. Fuck 'em, nobody cares about
> them anyway, especially since we all know perfectly well they're just a
> bunch of fat unshowered virgin slobs living in their parent's basement
> and jerking to "7 of 9".
>
>
>
> ...Right?
>
>
>
> Or, of course, we could just go with the classic favorite: "It's just
> business."
>

So the basic premise of the argument is that if we can't make everyone happy we shouldn't do anything at all? Let me pose you this question. If a piece of software did something for you that you absolutely had to do and nothing else did, but had a non-native widget UI, would you use that piece of software?

Most people, even the prideful ones, would just use it, because not using the software is worse than the UI decisions by the designer.

Also, mobile, particularly WinRT, but also Android, do not enforce a look, in fact Android enshrines the idea of many different looks for widgets, my S3 is NOT the vanilla Android look. Only iOS enforces a "look" but it's still overridable. And WinRT doesn't even have the concept of OS enforced widgets looks, all it has a default style.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Mon, 20 May 2013 17:04:40 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 15:50:06 -0700
> "Adam Wilson" <flyboynw@gmail.com> wrote:
>
>> On Mon, 20 May 2013 15:21:22 -0700, Nick Sabalausky
>> <SeeWebsiteToContactMe@semitwist.com> wrote:
>>
>> >
>> > I still have a hard time believing that it's realistic for it take
>> > take everything into account. *Even* if you go to all the effort to
>> > make every render and behavior pixel-perfect, you're *still*
>> > failing to account for all of the following things, all of which
>> > actually *exist*:
>> >
>> > - Software to allow the user to custom-reskin the system. Yes, even
>> > on Windows this exists, and has for a looong time. Getting a
>> > third-party GUI toolkit compatible with this would likely be quite
>> > difficult, if even possible.
>> >
>>
>> What if as a UI designer I know that I want to specifically disallow
>> skinning? It's not even that hard of a decision to reach. If the
>> skinning changes the layout metrics at all (margin, padding, size,
>> even shape), my app can end up looking terrible and I have to take a
>> support call for a case that I couldn't have possibly dreamed up.
>>
>
> Basing software decisions upon worries of "What if some user shoots
> himself and calls our support?" is *always* a bad idea.
>

Is it though? Because regardless of whether or not they should call me, they will, and I will have to spend money to deal with it. Again, I have real problems that are clashing with ideology. When that happens the engineer in me demands that I address the real problems.

> The user overrides the developer/designer. Always. The user is the
> whole reason for *anything* we do in this field. The user may as well be
> God - if they want to do something questionable, we can raise warnings,
> but it is *absolutely* not our place to prevent it. As soon as you
> start down that route, anything you do becomes a pointess waste that
> defeats its own reason for existence.
>
>

Why? The user mostly doesn't care as long as it works and solves their problem, I personally spend less and less time customizing my environments for two-fold reasons, I have an every growing number of them, and I care less and less, just get out of my way and let me work. Don't make me decide on a hundred details before I can get started.

>> > - On windows, I use a program called KatMouse that allows me to
>> > scroll any control by just pointing at it and using my mouse's
>> > scroll-wheel. No need to manually "focus" the control before the
>> > retarded Win system allows me to scroll it. This is literally my #1
>> > favorite windows program. But this obviously doesn't work on
>> > programs that merely *emulate* the system's look-and-feel, no
>> > matter how meticulous the emulation. Hell, even the UI changes in
>> > "native" MS-developed Vista and Win7 break it at least half the
>> > time.
>> >
>>
>> I'd say it's on the developers of KatMouse to get their crap
>> together. It sounds like their development model is "don't upgrade
>> from WinXP because we like that one."[...]
>
> You're missing the point:
>
> The point is NOT that "XP -> 7 should be seamless for all software". I
> don't believe that, and I would never claim it or deliberately imply it.
>
> The point is that even the most *meticulous* and convincing native
> emulation is *still* insufficient (and ultimately a big waste of time).
>
> Should it be the responsibility of the program itself support newer
> versions of Win? Obviously. (Unfortunately, KatMouse appears to
> be closed-source abandonware, but that's completely beside the point.)
>
> Should it be the responsibility of the program itself to support the
> various non-native third-party GUIs just because some
> self-important GUI developers didn't feel like playing ball and
> decided that *their* internal conveniences were more important than
> their users, the very people for whom the all this software exists
> in the first place? *Absolutely not*.
>
>
>> You may like it, by I've never even
>> heard of it, and my guess is that almost nobody else has either.
>>
>
> popularity != importance
> popularity != value
> popularity != worthiness
>
> (popularity != a goddamn thing)
>
> It is unreasonable to expect GUI developers or GUI designers to
> explicitly support various tools like KatMouse? Absolutely. It is
> definitely unreasonable. And that's *exactly* why non-native GUIs are
> horrible idea.
>
>
>> > - Tools to reveal the value behind "******"-filled password boxes.
>> >   Sounds like a black-hat tool, but I've personally had legitimate
>> >   need to use it.
>> >
>>
>> Ehrm, TBH, I consider breaking those tools a good thing. Yes there
>> may be legitimate uses, but the number if illegitimate uses far
>> exceeds the benefit.
>>
>
> I strongly disagree:
>
> First of all, there is very little, if any, illegitimate use of this
> that doesn't require *at least* as significant a security breach to
> have *already* occurred.
>
> Secondly, we're not babysitters or self-appointed police here. To
> engage in such a level of control is *already* a very serious breach
> of our moral obligations.
>
>

In the real world, yes, we are. You see, it's a small inconvenience known as the lawsuit. Specifically that I am legally liable for any and all security vulnerabilities within my product. There is case-history going back to support this since the dawn of legal systems. It is ironclad, ideology will not change it. I consider cross-process of a UI a MAJOR security problem because it allows malicious software to modified my software in subtle ways that compromise the security of the system. And apparently I am not the only one who thinks this way because every mobile OS available today does not allow ANY kind of cross-process UI manipulation of any kind, going so far as to sandbox each app. Where is your outrage over Android or iOS or WinRT or Blackberry or Symbian?

>> > - Anything else that involves either GUI-introspection or adding a
>> >   cross-application UI feature. There's plenty of other
>> >   entirely valid use-cases.
>> >
>>
>> What is the use case for GUI introspection?
>>
>
> Just for example, Spy++ or any similar such developer tool. Or GUI
> macros. Those are just off the top of my head. I'm sure people can, and
> have, thought of any number of other different uses.
>

GUI macros work on WPF apps. Snoop does what Spy++ does.

>>
>> Manipulating a UI from another process is bad, evil, and a massive
>> security problem, I'd say that disallowing it is a service to the
>> world.
>>
>
> I couldn't disagree more. I don't believe for a second that that's
> even the slightest bit different from saying "Using a computer is bad,
> evil, and a massive security problem; disallowing them is a service to
> the world."
>
> We're not Big Brother and I, for one, refuse to be party to anything
> even remotely smelling as such, which is something (ie, "Big Brother")
> that I very much believe your views on our responsibilities as
> developers *do*, by necessity, constitute.
>

Have you ever built any software where you are legally liable for any security holes your software opens up? My guess is no. Because if you had, you'd get where I am coming from.

Ideology is fine, right up until you have to meet the real world. Do you honestly expect your users to each become security experts? Such a thought is laughable on the face of it. They have neither the time nor the interest, and nor should they, it is not a productive use of their time. This is why the law makes it MY fault for security flaws, because there is not, and can be no, reasonable expectation that they are security experts, that's MY job.

Ergo, allowing cross-process UI manipulation is inherently wrong, it's also legally and ethically wrong.  Putting my users at risk in the name of ideology is so wrong that I am dry heaving at the thought. Incidentally, this is why no mobile OS ever allows it, it's WAY to legally risky. Not even Google can make that lawsuit go away.


Nick, I hate to break it to you, but you are so far out on the extreme end of the scale on this one that it will be impossible to advance technology and keep you happy, so I'll have to leave you behind, because the 99% want there software to just work, and could care less how it does it. I don't like leaving people behind and pissing them off, but I have to go where the majority goes, otherwise I'm just a penniless artist with a rigid ideology and no friends.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Mon, 20 May 2013 16:50:47 -0700, Peter Williams <pwil3058@bigpond.net.au> wrote:

> On 21/05/13 08:49, Adam Wilson wrote:
>>
>> I'd be willing to lead the project, I'm just not sure I am the right
>> person to do so. I have a vision, and the skeleton of a design, but no
>> code. I am willing, but my ability is a question mark...
>>
>
> I'd volunteer to be a foot soldier on this project as I'd like D to have a useful GUI capability.  At the moment, my experience of GUI programming is at the user of the API end of the spectrum (mostly using PyGTK to write GUI wrappers for command line programs to make my life easier) but I think I'm a quick learner.  Also as a GUI API user I have some idea of the sorts of thing that make a good API.
>
> If D had a usable GUI API I would port at least one of my current PyGTK programs to D as it would benefit from better number crunching capability than Python possesses.
>
> So, if this gets up, give me a call.
> Peter
>

I'd love to get this up and running but I think we've got a blocker right now in D and that is the lack of package import, the GUI system is going to be a monster no matter how it's sliced and I'd lack to avoid the std.datetime effect. Sorry Jonathan Davis!

Once we get package import into D we can start building out the basics. Do you have any experience with concurrent hashmaps by chance? Or any other types of containers?

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Tuesday, 21 May 2013 at 02:47:59 UTC, Adam Wilson wrote:
> could care less

http://www.youtube.com/watch?v=om7O0MFkmpw

Sorry...