On Friday, 6 March 2015 at 19:30:14 UTC, Aram wrote:
> On Thursday, 5 March 2015 at 18:42:56 UTC, Vadim Lopatin wrote:
>> On Thursday, 5 March 2015 at 15:09:55 UTC, Aram wrote:
>>> Unfortunately, if it doesn't cover all major PC platforms, it doesn't suit me (Mac OS is not supported). I would like to have all backends working on all platforms, as I lack knowledge to implement my own backends for X and Mac OS.
>>
>> Why not? SLD2 backend works ok on Mac (as well as on linux and windows).
>> But on mac native menus are not supported. Instead, menu is show at the top of window.
>
> Ok, I will take a look at it. By the way, what is SDL2 in brief?

https://www.libsdl.org/index.php

On Friday, 6 March 2015 at 19:30:14 UTC, Aram wrote:
>
> By the way, what is SDL2 in brief?

"Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D."

http://www.libsdl.org/

-Wyatt

On Fri, 06 Mar 2015 18:55:31 +0000, Ola Fosheim Grøstad wrote:

> On Friday, 6 March 2015 at 17:03:51 UTC, ketmar wrote:
>> but i like it's core simplicity (oh, no, full xorg is a beast, especially with
> 
> Opening a simple window with nothing on it in a portable and compliant
> manner using xlib is at least 800 lines of code...
> Simple!

ahem...

  //import iv.x11.X, iv.x11.Xlib;
  import iv.x11;
  import iv.writer;


  int main () {
    Display *dpy = XOpenDisplay();
    if (!dpy) {
      errwriteln("FATAL: XOpenDisplay failed!");
      return 1;
    }

    int screen = DefaultScreen(dpy);

    Window window = XCreateSimpleWindow(
      dpy,
      DefaultRootWindow(dpy),  //parent window
      0, 0, 323, 200, 0,           //x, y, width, height, border_width
      BlackPixel(dpy, screen), //border_color
      WhitePixel(dpy,screen)   //back_color
    );

    writefln!"dpy=%s; wid=%s"(dpy, window);

    XStoreName(dpy, window, "Example window");
    XSelectInput(dpy, window, ExposureMask);
    XMapWindow(dpy, window);

    Atom wmDeleteMessage = XInternAtom(dpy, "WM_DELETE_WINDOW", False);
    XSetWMProtocols(dpy, window, &wmDeleteMessage, 1);

    GC gc = DefaultGC(dpy, screen);

    bool running = true;
    while (running) {
      XEvent event;
      KeySym keySym;
      while (running && XPending(dpy)) {
        XNextEvent(dpy, &event);
        switch (event.type) {
          case ClientMessage:
            if (cast(Atom)event.xclient.data.l[0] == wmDeleteMessage) {
              writeln("delete message");
              running = false;
            }
            break;
          case Expose:
            auto ee = cast(XExposeEvent*)&event;
            writefln!"expose event(dpy=%s, wid=%s); serial=%s; send=%s; x=
%s; y=%s; count=%s"
               (ee.display, ee.window, ee.serial, ee.send_event, ee.x,
ee.y, ee.count);
            XDrawString(dpy, cast(Drawable)window, gc, 10, 16, "Hello
world!", 12);
            break;
          default:
        }
      }
    }

    XUnmapWindow(dpy, window);
    XDestroyWindow(dpy, window);
    XCloseDisplay(dpy);

    return 0;
  }

On Saturday, 7 March 2015 at 09:27:42 UTC, ketmar wrote:
> On Fri, 06 Mar 2015 18:55:31 +0000, Ola Fosheim Grøstad wrote:
>
>> On Friday, 6 March 2015 at 17:03:51 UTC, ketmar wrote:
>>> but i like it's core simplicity (oh, no, full xorg is a beast,
>>> especially with
>> 
>> Opening a simple window with nothing on it in a portable and compliant
>> manner using xlib is at least 800 lines of code...
>> Simple!
>
> ahem...

You are cheating. You first have to find the optimal visual using XGetVisualInfo. You need to create an appropriate colormap. You need to set WM hints using XSetWMProperties. And so on...

On Sat, 07 Mar 2015 16:30:27 +0000, Ola Fosheim Grøstad wrote:

> On Saturday, 7 March 2015 at 09:27:42 UTC, ketmar wrote:
>> On Fri, 06 Mar 2015 18:55:31 +0000, Ola Fosheim Grøstad wrote:
>>
>>> On Friday, 6 March 2015 at 17:03:51 UTC, ketmar wrote:
>>>> but i like it's core simplicity (oh, no, full xorg is a beast, especially with
>>> 
>>> Opening a simple window with nothing on it in a portable and compliant
>>> manner using xlib is at least 800 lines of code...
>>> Simple!
>>
>> ahem...
> 
> You are cheating.

in no way. i even did more than you asked, as you told to "open a simple window with nothing on it", and i wrote text there.

> You first have to find the optimal visual using XGetVisualInfo. You need to create an appropriate colormap.

for what reason? it's always guaranteed to have at least black and white colors.

> You need to set WM hints using XSetWMProperties.

i don't need 'em. my Fluxbox is happy as it is (and much other WMs too).

> And so on...

there is nothing more. simple as it is.

On Saturday, 7 March 2015 at 17:56:21 UTC, ketmar wrote:
> there is nothing more. simple as it is.

You are cheating. :P

And there is nothing simple about X11 if you follow the protocols and want to do real work, it is outdated by a wide margin, and so is the use scenario: running low level UI events/graphic commands over ethernet replacing TTYs with the graphical equivalent... It was outdated 25 years ago!

X11 is the Frankenstein of  UI and has probably made a big dent in Linux' ability to reach a more casual audience... It belongs in a museum...

On Sat, 07 Mar 2015 18:10:36 +0000, Ola Fosheim Grøstad wrote:

> On Saturday, 7 March 2015 at 17:56:21 UTC, ketmar wrote:
>> there is nothing more. simple as it is.
> 
> You are cheating. :P

in no way. ;-)

> And there is nothing simple about X11 if you follow the protocols and want to do real work

i wrote some GUI toolkits for X11 in C, and i must say that X11 is simple.

> it is outdated by a wide margin

yes, we need X12. but not from packard, he is insanely dumb.

> and so is the use
> scenario: running low level UI events/graphic commands over ethernet
> replacing TTYs with the graphical equivalent... It was outdated 25 years
> ago!

it wasn't outdated. and i must say that i'm using this feature on dayly basis. by the way, X11 is not restricted to do only "low level" things.

if only that shitheads didn't kill XIE...

> X11 is the Frankenstein of  UI

X11 was never an UI system. it's WINDOW system. and window is just a rectangular area on a display. that's it.

> and has probably made a big dent in
> Linux' ability to reach a more casual audience...

ah, one of the things of which i can't care less. ;-)

> It belongs in a museum...

there is no alternative. i'd be happy to get one, but there simply isn't.

On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote:
> Hi all
>
> I've been thinking over a GUI framework for D for some time, and ended up with idea expressed by Andrew Fedoniouk here: http://www.digitalmars.com/d/archives/digitalmars/D/32633.html. That is, having a separate drawing layer, and widgets built on top of it. But since it has already been discussed 9 years ago, I wonder if such a framework has ever been implemented.
>
> In that duscussion many participants agreed that Qt would be a good foundation, but had very restrictive license. Things have changed since then, and Qt now is available under LGPL, which, to my undestanding, makes it suitable for the purpose of standard GUI library (please correct me if I am wrong on this). The license, of course, may change in the future, preventing us from using their updates for our drawing engine. But if we are able to start using the engine now, in the future we can maintain the updates ourselves.
>
> Now, how I envision the library's design:
>
> The library will be mostly implemented in D, except for drawing engine and event loop, which are system-dependent. Those two parts will be extracted from Qt into a separate library which will be linked to by the rest of framework either statically or dynamically. There will be bindings for sending drawing instructions to drawing engine, as well as for retrieving system and GUI events from event loop.
>
> The system-independent part will mimic architecture of Qt. However, for maximum flexibility and customizability, GUI will utilize QML+CSS approach, and Qt's layout manager classes will be dropped completely. Also there is no need to port classes that are available in D, such as collections and strings.
>
>
> If there is no standard GUI for D yet, and if LGPL license fits our purpose, then I am looking for 2-3 Qt experts to join me and build the framework.
>
> Thanks,
> Aram

I would rather have a GUI framework inspired by JavaFX, plus some features that could be added on top of it, that are related to the fact that D programmers can utilize hardware directly. JavaFX is in my humble opinion one of the best designed GUI APIs in existence today. Similar D API would be smaller because we would get rid of typical Java bloat.

On Mon, 2015-03-09 at 08:56 +0000, Dejan Lekic via Digitalmars-d wrote: […]
> 
> I would rather have a GUI framework inspired by JavaFX, plus some features that could be added on top of it, that are related to the fact that D programmers can utilize hardware directly. JavaFX is in my humble opinion one of the best designed GUI APIs in existence today. Similar D API would be smaller because we would get rid of typical Java bloat.

And using GroovyFX to code it gets rid of much of the Java bloat. Sadly the JavaFX team have created a nice piece of infrastructure but forget to mention that coding it using Groovy is way easier that using Java.

Of course using a UI development framework such as Griffon makes things even easier.

http://new.griffon-framework.org/


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Please don't use SDL2 and such as basis, or OpenGL with glBegin+glReadPixels without FBOs and PBOs (not Pbuffers). I'm a GL driver dev (userspace) for a smaller company, and I see too much gore in popular software like that (gnome3 is the most-horrific). A fully-featured GUI with GL needs only a thin wrapper for glXGetProcAddress, GL context creation, BitBlt-like things and font-glyph cache (or better yet, signed-distance-field text rendering). Something like this:

Base (sans clipping, I haven't ported it from asm yet):
https://github.com/idinev/pub_toys/tree/master/Blitters/oDraw

SDF text:
https://www.mapbox.com/blog/text-signed-distance-fields/

Also, GL should be optional, just like with Qt; it introduces noticeable lag of 16 to 48ms while being a resource hog unnecessary for most apps. I could help with implementing the abstraction layer and create a software blitter (I was professionally doing such stuff before, for GUI toolkits and stuff; but then again this stuff is trivial).

A 32-bit backing-store is always vital (DDB+GDI dibsection, GL texture and such). Qt has it (and implemented really-well) and that's the first pixel-related thing we should implement. BGRA8 will be the best format (blue in LSB).
A 9-cell blit will also be vital functionality.