On 2011-04-06 10:39, Matthias Pleh wrote:
> Am 06.04.2011 09:00, schrieb Jacob Carlborg:
>>
>> I think gtkD is out of the question since it's not using native
>> controls. Don't know about QtD, if I recall correctly it, at least,
>> looks quite native. But I would guess it would too hard to find whole
>> int that, specially on Mac OS X.
>
>
> Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
> colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt
> make really good job in imitating the native Theme. (except OSX, which
> is a little bit special)
>

As expected. I'm not sure but it seems that Mac OS X Lion has a new style on the regular push buttons. Then Qt needs to start all over (almost).

-- 
/Jacob Carlborg

Am 06.04.2011 11:40, schrieb Nick Sabalausky:
> "Matthias Pleh"<jens@konrad.net>  wrote in message
> news:inh91t$1854$1@digitalmars.com...
>> Am 06.04.2011 09:00, schrieb Jacob Carlborg:
>>>
>>> I think gtkD is out of the question since it's not using native
>>> controls. Don't know about QtD, if I recall correctly it, at least,
>>> looks quite native. But I would guess it would too hard to find whole
>>> int that, specially on Mac OS X.
>>
>>
>> Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
>> colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt
>> make really good job in imitating the native Theme. (except OSX, which is
>> a little bit special)
>>
>
> My understanding is that Qt also has a compile-time flag that will make it
> actually use the real Win32 controls.
>
>

No! When compiling the Qt-library, you can specify a flag for the theme to build. The controls appears then with this theme.

On windows you can easaly test this, with Spy++.
I've just created a simple window with QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.
But ther is only one win32-control and this is the main-window!
You can see this also on the traffic of the windowsmessages.
This is so on Windows, maybe Qt use more native controls on other platforms?

The problem with OSX is, as I know, that some controls not only look different, but are also different arranged, and this make it more difficult to emulate.

°Matthias

On 2011-04-05 23:07:33 -0400, Adam D. Ruppe <destructionator@gmail.com> said:

> Note: I just updated my simpledisplay.d. My color constructor
> said b = c when I meant this.b = c... hence everything was yellow!
> You can download again from the same place.

I played with it yesterday and never found why the blue channel didn't work!

By the way it works well with X11 on Mac OS X (if I change the "version (linux)" to "version (OSX)").

I also made a working OS X implementation (Cocoa).


> Nick Sabalausky wrote:
>> I haven't benchmarked or even tested this, and heck, maybe I'm just
>> a dinosaur, but for better speed and flexibility I'd recommend
>> something more like what I've attached.
> 
> Yea, that does sound better. Though I have a few comments...
> 
>> The width is statically-known, so the compiler can optimize the
>> index calculation from multiplication to shifts when appropriate.
> 
> One concern I have here is will it be an incompatible type with
> dynamic widths? i.e. an image loaded from a file? (I'll be hopefully
> cleaning up my png and bmp loaders in the near future to use with
> this.)

I don't think having fixed-size image will be a useful optimization, except perhaps if you manipulate a lot of tiny images of the same size.


> Maybe it could use an interface to smooth that over.
> 
> I actually had a similar fight with myself over Indexed vs TrueColor
> when writing the original thing. They really don't have compatible
> interfaces. Sure, you could do some kind of putpixel(uint data)
> for each of them, but it's not really the same.
> 
> So I think they should be separate types, with functions to convert
> back and forth. (both conversions being lossy in their own way..
> just because two palette entries have the same rgb values doesn't
> mean the two colors are semantically the same.)

Don't forget that there's actually much more colorspaces than indexed and RGB. There's RGBA (when you need semi-transparency), there's CYMB (for print), there's grayscale. And in some cases HSV or XYZ could be useful too. And for each of these someone might want different bit depth. Can't we make things flexible enough for that by using a template?

	final class Bitmap(Color) : Image {
		void opIndexAssign(int x, int y, Color color) {
			pixels[y * width + x] = Color(color);
		}

		size_t width, height;
		Color[] pixels;
	}

This way, you can have a bitmap of RGBColor, or RGBAColor (with an alpha mask), GrayColor, IndexedColor, or whatever color type you can come with, and algorithms can be reused.


> Wow, I'm off topic again. Anyway, for the event loop here, I'm
> thinking something similar to how std.concurrency does it might
> be a good approach: a bunch of delegates, matched to events by
> their signature. Simple signatures could be accepted as well
> as fancier ones.
> 
> // need to make a simple window separately here so it is persistent
> auto win = new DrawableWindow(width, height);
> 
> // still use an image the same way. Alternatively, DrawableWindow
> // could implement the same interface as Image, probably double
> // buffering internally anyway, so pretty much same implementation.
> auto image = new Image(width, height);
> 
> window.eventLoop(
>    50, // first parameter is the timeout. can be 0 to only react
>        // to events, but putting one in gives you an easy to use
>        // frame pulse for drawing
>    (int keyPressed) { // might be a struct KeyEvent rather than int
>         // react to the key
>    },
>    (int x, int y, int mouseButton) {
>         // react to a mouse click
>    },
>    () { // no params means your timeout happened, time to draw
>         // draw your frame...
> 
>         image.display(win); // this overload uses the existing
>                             // window and returns immediately
>                             // rather than making and waiting
>    }
>    // might also offer a platform specific msg, wParam, lParam
>    // so you could in theory do all of Win32 based on this same
>    // framework
> );

Overall, I really like this concept. I'd like it better if image.display(win) was replaced with "window.image = image" however.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2011-04-06 07:38:30 -0400, Matthias Pleh <jens@konrad.net> said:

> The problem with OSX is, as I know, that some controls not only look different, but are also different arranged, and this make it more difficult to emulate.

And it'll only become harder and harder. Have you seen in Mac OS X Lion the new tab control or the button groups (segmented controls in OS X parlance) which are now using an animated "slider" knob? And the new iOS-style scrollbars with a bounce effect? Nothing is impossible, but it'll take time for Qt to catch up with those changes.

<http://www.youtube.com/watch?v=B5k8x6jWXPw>

Meanwhile, Cocoa apps will get all this for free.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Nick Sabalausky wrote:

> "Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.3178.1301970383.4748.digitalmars-d@puremagic.com...
>> On 4/5/11, Nick Sabalausky <a@a.a> wrote:
>>> After all, I
>>> *really* want to get around to making my own web browser (based off
>>> either
>>> Mozilla or Chromium) - I'm getting really fed up with the current state
>>> of
>>> available web browsers. Well, and the web as a whole (god I fucking hate
>>> the
>>> web), but one step at a time, I guess).
>>
>> I'll be the first to install it.
>>
>> Btw, there's a full web browser example in the QtD sources. But it has to be ported to D2. And then you have to deal with any eventual bugs along the way. :]
> 
> Ha! I may not need to do much after all: I was just looking through Wikipedia's giant list of browsers, found a few that looked potentially promising, tried them all and...well, was mostly disappointed. But the *last* one I had left to try I've been really impressed with so far:
> 
> Arora (Qt/WebKit)
> http://code.google.com/p/arora/
> 
> I've only tried it breifly, but the UI is *actually nice*! Only modern browser out there with a UI that isn't absolutely horrid. I didn't even see *one* instance of invisible-text on my light-on-dark system, which is unbeleivavly rare among all software these days.
> 
> And it has a lot of essential stuff built in, like ad blocking, disableable JS, and a "ClickToFlash" which I haven't tried out yet. There's still a few things it seems like it might be missing, like equivalents to NoScript, BetterPrivacy and maybe DownloadHelper and DownThemAll, but most of those are less important to me, and even as it is right now it's a damn good start. Maybe I could add some of that remaining stuff, or heck, maybe even port the whole thing to D ;)

Even it it would involve looking at C++ code?

Did you know Arora *is* the Qt webbrowser example that got out of control and became a real browser? (it uses webkit)

iirc QtD has a sizeable chunk of that example already ported to D.

On 2011-04-06 13:38, Matthias Pleh wrote:
> Am 06.04.2011 11:40, schrieb Nick Sabalausky:
>> "Matthias Pleh"<jens@konrad.net> wrote in message
>> news:inh91t$1854$1@digitalmars.com...
>>> Am 06.04.2011 09:00, schrieb Jacob Carlborg:
>>>>
>>>> I think gtkD is out of the question since it's not using native
>>>> controls. Don't know about QtD, if I recall correctly it, at least,
>>>> looks quite native. But I would guess it would too hard to find whole
>>>> int that, specially on Mac OS X.
>>>
>>>
>>> Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
>>> colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt
>>> make really good job in imitating the native Theme. (except OSX,
>>> which is
>>> a little bit special)
>>>
>>
>> My understanding is that Qt also has a compile-time flag that will
>> make it
>> actually use the real Win32 controls.
>>
>>
>
> No! When compiling the Qt-library, you can specify a flag for the theme
> to build. The controls appears then with this theme.
>
> On windows you can easaly test this, with Spy++.
> I've just created a simple window with
> QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.
> But ther is only one win32-control and this is the main-window!
> You can see this also on the traffic of the windowsmessages.
> This is so on Windows, maybe Qt use more native controls on other
> platforms?
>
> The problem with OSX is, as I know, that some controls not only look
> different, but are also different arranged, and this make it more
> difficult to emulate.
>
> °Matthias

DWT handles that fine.

-- 
/Jacob Carlborg

Am 06.04.2011 14:49, schrieb Michel Fortin:
>      final class Bitmap(Color) : Image {
>          void opIndexAssign(int x, int y, Color color) {
>              pixels[y * width + x] = Color(color);
>          }
>
>          size_t width, height;
>          Color[] pixels;
>      }


Yep, exactly. I would implement it as template.

About the render backend, Nick mentioned.
In the first step, I would just draw all objects (lines, boxes, circles) to the buffer and then render it as image per gdi/xlib.

this render should ideally be in a single file, so other backends can be implemented (gdi/direct2d/cairo/xcb/cocoa/..)


°Matthias

Am 06.04.2011 15:21, schrieb Jacob Carlborg:
> On 2011-04-06 13:38, Matthias Pleh wrote:
>> Am 06.04.2011 11:40, schrieb Nick Sabalausky:
>>> "Matthias Pleh"<jens@konrad.net> wrote in message
>>> news:inh91t$1854$1@digitalmars.com...
>>>> Am 06.04.2011 09:00, schrieb Jacob Carlborg:
>>>>>
>>>>> I think gtkD is out of the question since it's not using native
>>>>> controls. Don't know about QtD, if I recall correctly it, at least,
>>>>> looks quite native. But I would guess it would too hard to find whole
>>>>> int that, specially on Mac OS X.
>>>>
>>>>
>>>> Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
>>>> colorPicker, ... but most controls are drawn by the PaintEnginge.
>>>> But Qt
>>>> make really good job in imitating the native Theme. (except OSX,
>>>> which is
>>>> a little bit special)
>>>>
>>>
>>> My understanding is that Qt also has a compile-time flag that will
>>> make it
>>> actually use the real Win32 controls.
>>>
>>>
>>
>> No! When compiling the Qt-library, you can specify a flag for the theme
>> to build. The controls appears then with this theme.
>>
>> On windows you can easaly test this, with Spy++.
>> I've just created a simple window with
>> QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.
>> But ther is only one win32-control and this is the main-window!
>> You can see this also on the traffic of the windowsmessages.
>> This is so on Windows, maybe Qt use more native controls on other
>> platforms?
>>
>> The problem with OSX is, as I know, that some controls not only look
>> different, but are also different arranged, and this make it more
>> difficult to emulate.
>>
>> °Matthias
>
> DWT handles that fine.
>


Yeah, that's true.
You will only get the real platform feeling, when you use the native controls. I was always irritated by the unusual widget of swing.
So such an approach like DWT looks always handier, but don't forget,
you have to maintain all that code for _all_ platforms.
You always get pro's and con's.

°Matthias

On 2011-04-06 16:37, Matthias Pleh wrote:
> Am 06.04.2011 15:21, schrieb Jacob Carlborg:
>> On 2011-04-06 13:38, Matthias Pleh wrote:
>>> Am 06.04.2011 11:40, schrieb Nick Sabalausky:
>>>> "Matthias Pleh"<jens@konrad.net> wrote in message
>>>> news:inh91t$1854$1@digitalmars.com...
>>>>> Am 06.04.2011 09:00, schrieb Jacob Carlborg:
>>>>>>
>>>>>> I think gtkD is out of the question since it's not using native
>>>>>> controls. Don't know about QtD, if I recall correctly it, at least,
>>>>>> looks quite native. But I would guess it would too hard to find whole
>>>>>> int that, specially on Mac OS X.
>>>>>
>>>>>
>>>>> Qt (and so QtD) use some native controls for Dialogs, e.g.:
>>>>> FilePicker,
>>>>> colorPicker, ... but most controls are drawn by the PaintEnginge.
>>>>> But Qt
>>>>> make really good job in imitating the native Theme. (except OSX,
>>>>> which is
>>>>> a little bit special)
>>>>>
>>>>
>>>> My understanding is that Qt also has a compile-time flag that will
>>>> make it
>>>> actually use the real Win32 controls.
>>>>
>>>>
>>>
>>> No! When compiling the Qt-library, you can specify a flag for the theme
>>> to build. The controls appears then with this theme.
>>>
>>> On windows you can easaly test this, with Spy++.
>>> I've just created a simple window with
>>> QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.
>>> But ther is only one win32-control and this is the main-window!
>>> You can see this also on the traffic of the windowsmessages.
>>> This is so on Windows, maybe Qt use more native controls on other
>>> platforms?
>>>
>>> The problem with OSX is, as I know, that some controls not only look
>>> different, but are also different arranged, and this make it more
>>> difficult to emulate.
>>>
>>> °Matthias
>>
>> DWT handles that fine.
>>
>
>
> Yeah, that's true.
> You will only get the real platform feeling, when you use the native
> controls. I was always irritated by the unusual widget of swing.
> So such an approach like DWT looks always handier, but don't forget,
> you have to maintain all that code for _all_ platforms.
> You always get pro's and con's.
>
> °Matthias

Yes that's true. I don't know how much different it would be compared to a non-native framework since there you have all the different themes to maintain.

-- 
/Jacob Carlborg

>
> Yes that's true. I don't know how much different it would be compared to
> a non-native framework since there you have all the different themes to
> maintain.
>

Maybe, the best aproach would be, when you implement the basic framework flexible. E.g. a default rendering engine, where you can
draw you own controls, but keep it possible to add native controls.
So you always choose the best way, if a platform bring out a new control or a new look. But I down't know, if such different approaches
cann merged together?


BTW: under what license is DWT?
Can part of it relicensed under boost? (e.g. if we would reuse part of it)


°Matthias