On 2011-04-09 02:11, Adam D. Ruppe wrote:
> bearophile wrote:
>> I'd like something like this in Phobos
>
> Me too. It's still pretty far from good enough right now, but
> that's where I want ultimately want it.
>
> My only concern is I don't want Phobos to depend on Xlib unless
> the module is actually imported. I don't think it will be a problem,
> but if it means a hello world won't run on a text only machine, that
> won't be ok.

You can always dynamically link to the functions.

>> I suggest something simpler like:
>
> Yeah, moving to opIndex is something I plan to do. But, I don't
> really like using a tuple for this - a regular struct makes it
> a little clearer what's going on, and can be made more efficient.
> (In the other thread, Nick suggested making it a simple uint
> internally, using property functions to emulate other outside
> faces. I like that.)
>
> A struct might also have accessors with different color types
> too.
>
>> I suggest something like this, to swap the two image buffers
>
> That's not really what you're doing there - display actually
> pops up a new window and waits for the user to close it.
>
>> Plus maybe some image.event(); reader with callbacks...
>
> What would it do?


-- 
/Jacob Carlborg

On 04/09/2011 11:45 PM, Adam D. Ruppe wrote:

> There's still a handful of little things and a lot of error checking
> needed, but I'm pretty happy with this as the screen drawing base.
> It covers all the easy stuff. The hard stuff will be in platform
> independent images.
>
> Anyway, here's the updated simpledisplay.d:
>
> http://arsdnet.net/dcode/simpledisplay.d

That's great, Adam, thank you!

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 04/10/2011 02:58 AM, Adam D. Ruppe wrote:
> A note: since I posted last, I changed my mind on something, and
> bearophile, I rather doubt you'll like it...
>
> Before, it was drawRectangle(int x1, int y2, int width, int height);
>
> Now, it is drawRectangle(Point upperLeft, Size size);
>
> So, at the usage, you now need to put in some more parenthesis
> and say what you mean:
>
> painter.drawRectangle(Point(0, 0), Size(win.width, win.height));
>
>
> Why did I do this? Well, consider the following:
>
> drawRectangle(int x1, int y1, int x2, int y2);
>
> (This is, in fact, the signature in Windows GDI, whereas Xlib
>   user width/height.)
>
>
> The types there are no different than the above, but meaning has
> changed. I'd be ok with saying "RTFM" to avoid having to use
> the structs.
>
> But, RTFM doesn't let you overload it, whereas the types do. Now,
> it can offer both
>
> drawRectangle(Point upperLeft, Size size);
>
> *and*
>
> drawRectangle(Point upperLeft, Point lowerRight);
>
> I'm sure you were thinking about named arguments for a moment
> there about width/height vs x2/y2. I did too. But, named arguments
> don't really exist in D (you can do them via library magic but not
> without) so it's moot, and I don't believe named arguments would
> offer the overloading possibilities, which I like. It can save
> some math while being quite natural.
>
> The Point struct also makes drawPolygon look a lot better, so
> it's of general use.

That was about the first change I intended to do on my side, after reading your code :-)
In addition to the practical side you describe well, Point (or maybe better Position) is a nearly necessary semantic/conceptual type on the user side.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 04/10/2011 03:03 AM, Cliff Hudson wrote:
> One thing to consider, since I was impacted by this when writing a WPF app a
> while back, is the difference between a 2-Vector and a Point.  In
> particular, Vectors typically have some very useful methods on them, like
> addition, rotation, transformations, etc. which frequently are not
> associated with the Point type.  I don't know if you have or plan to support
> this data type, but at least having simple transforms to/from Vector would
> be nice.

Very good remark. Eg a line can be defined by a point and a vector (a single-point one).

denis
-- 
_________________
vita es estrany
spir.wikidot.com

On Apr 9, 11 04:26, Adam D. Ruppe wrote:
> We discussed this first in the GUI library thread, but since it
> meandered so much, I decided to split off into a new subject. Much
> of what I say here will be old to anyone who saw the previous thread.
> There's some new stuff nearer to the bottom though.
>
> I, with input from others, have started writing a little module
> for simple uses of a display. You can write to a bitmap, display it
> to a window, and handle events all in an easy way. The basics are
> cross platform, but you can use native function calls too.
>
> http://arsdnet.net/dcode/simpledisplay.d
>
> It's still very much in progress, but I think it's now at the point
> where the direction I'm taking it is clear.
>
[snip]

Thanks for the great work!

Taking the version on that link, I have ported it to use the native Cocoa/Core Graphics in OS X, instead of X11. You can check out the diff in https://github.com/kennytm/simpledisplay.d/commit/a790.

Only Snow Leopard (10.6) is supported.

I have only tested that it works on the pendulum example and the HSL picker, so things like drawText and drawPixel may not work properly yet. The implementation part is quite messy right now due to Objective-C.

Since dmd does not have "pragma(framework)", you'll need to supply the "-L-framework -LAppKit" options to dmd to link it.

And a few things:

 1. *Please use spaces instead of tabs.*
 2. Color's constructor's arguments should better be "red" "green" "blue" "alpha" rather than "a" "b" "c" "d".
 3. The unit of "pulseTimeout" should be documented (milliseconds).
 4. In the function "fromHsl", there is a (h is real.nan). However, 'is' on primitives is reduced to '==' and (nan == nan) is false, so (h is real.nan) will always be false. You should use std.math.isNaN().
 5. Why use the ANSI version (LoadIconA, etc.), not the Unicode version (LoadIconW, etc.) of API on Windows? I think the latter is preferred.

KennyTM~ wrote:
> Taking the version on that link, I have ported it to use the native Cocoa/Core Graphics in OS X, instead of X11

Thanks!

> 1. *Please use spaces instead of tabs.*

Spaces are the spawn of Satan! I hate them, but when it comes time to submit to phobos, I'll run a find/replace of them so it's consistent with the prevailing style there. Until then though, I'll write it in my native style... so these early drafts will remain tabs, but spaces will be used in the final copy.

> 2. Color's constructor's arguments should better be "red" "green"
> "blue" "alpha" rather than "a" "b" "c" "d".
> 3. The unit of "pulseTimeout" should be documented (milliseconds).

Indeed.

>  4. In the function "fromHsl", there is a (h is real.nan).
> However, 'is' on primitives is reduced to '==' and (nan == nan)
> is false, so (his real.nan) will always be false. You should use
> std.math.isNaN().

Ah, so that's what it is. I was sure it was some form of "is nan" but it's not something I use often so I assumed it was like null.

Changed.

> 5. Why use the ANSI version (LoadIconA, etc.), not the Unicode
> version (LoadIconW, etc.) of API on Windows? I think the latter
> is preferred.

Yeah. core.sys.windows.windows is woefully incomplete though, and
only defined the A versions. Since I was already sick of
copy/pasting headers after Xlib, I took the path of least
resistance and aliased to what it had. (Annoyingly though, I still
had to copy/paste a bunch of GDI prototypes! Not a big deal -
structs and enums are way more painful than functions, but
still, aaargh.)

I'll fix it up next time I have some time to kill. They're all aliased in one place so it will be easy to find.

"KennyTM~" <kennytm@gmail.com> wrote in message news:int88l$uaf$1@digitalmars.com...
> On Apr 9, 11 04:26, Adam D. Ruppe wrote:
>> We discussed this first in the GUI library thread, but since it meandered so much, I decided to split off into a new subject. Much of what I say here will be old to anyone who saw the previous thread. There's some new stuff nearer to the bottom though.
>>
>> I, with input from others, have started writing a little module for simple uses of a display. You can write to a bitmap, display it to a window, and handle events all in an easy way. The basics are cross platform, but you can use native function calls too.
>>
>> http://arsdnet.net/dcode/simpledisplay.d
>>
>> It's still very much in progress, but I think it's now at the point where the direction I'm taking it is clear.
>>
> [snip]
>
> Thanks for the great work!
>
> Taking the version on that link, I have ported it to use the native Cocoa/Core Graphics in OS X, instead of X11. You can check out the diff in https://github.com/kennytm/simpledisplay.d/commit/a790.
>
> Only Snow Leopard (10.6) is supported.
>
> I have only tested that it works on the pendulum example and the HSL picker, so things like drawText and drawPixel may not work properly yet. The implementation part is quite messy right now due to Objective-C.
>
> Since dmd does not have "pragma(framework)", you'll need to supply the "-L-framework -LAppKit" options to dmd to link it.
>
> And a few things:
>
>  1. *Please use spaces instead of tabs.*

What, so that he can force his indentation size on everyone else that works on the code? Or so that using the left/right arrow keys within the indentation zone requires an unnessesaraly large number of keypresses?

And frankly, I this strategy renders all the pro-space and pro-tab arguments obsolete, and it's still based on tabs anyway:

http://nickgravgaard.com/elastictabstops/

Spaces for indentation are just the worst of all worlds. And it's a total abuse of what space is even for in the first place.

Am 11.04.2011 07:00, schrieb Nick Sabalausky:
> "KennyTM~" <kennytm@gmail.com> wrote in message news:int88l$uaf$1@digitalmars.com...
>> On Apr 9, 11 04:26, Adam D. Ruppe wrote:
>>> We discussed this first in the GUI library thread, but since it meandered so much, I decided to split off into a new subject. Much of what I say here will be old to anyone who saw the previous thread. There's some new stuff nearer to the bottom though.
>>>
>>> I, with input from others, have started writing a little module for simple uses of a display. You can write to a bitmap, display it to a window, and handle events all in an easy way. The basics are cross platform, but you can use native function calls too.
>>>
>>> http://arsdnet.net/dcode/simpledisplay.d
>>>
>>> It's still very much in progress, but I think it's now at the point where the direction I'm taking it is clear.
>>>
>> [snip]
>>
>> Thanks for the great work!
>>
>> Taking the version on that link, I have ported it to use the native Cocoa/Core Graphics in OS X, instead of X11. You can check out the diff in https://github.com/kennytm/simpledisplay.d/commit/a790.
>>
>> Only Snow Leopard (10.6) is supported.
>>
>> I have only tested that it works on the pendulum example and the HSL picker, so things like drawText and drawPixel may not work properly yet. The implementation part is quite messy right now due to Objective-C.
>>
>> Since dmd does not have "pragma(framework)", you'll need to supply the "-L-framework -LAppKit" options to dmd to link it.
>>
>> And a few things:
>>
>>  1. *Please use spaces instead of tabs.*
> 
> What, so that he can force his indentation size on everyone else that works on the code? Or so that using the left/right arrow keys within the indentation zone requires an unnessesaraly large number of keypresses?
> 

Yeah.
Indent with tabs, align with spaces.

I find reading code with two or eight spaces for indentation hard to read. However both styles are widely used.. if everybody just indented with tabs and configured his editor to display 2/4/8/42 spaces for a tab everybody could be happy.

> And frankly, I this strategy renders all the pro-space and pro-tab arguments obsolete, and it's still based on tabs anyway:
> 
> http://nickgravgaard.com/elastictabstops/
> 

Hmm looks neat, but I'm not sure I really need that.

> Spaces for indentation are just the worst of all worlds. And it's a total abuse of what space is even for in the first place.
> 

The only thing that is more horrible than indentation with spaces is mixing indentation with spaces and tabs so it's completely broken when your editor uses another tab-width than the authors editor.

Cheers,
- Danie

Nick Sabalausky:

> What, so that he can force his indentation size on everyone else that works on the code? Or so that using the left/right arrow keys within the indentation zone requires an unnessesaraly large number of keypresses?

It's a module theoretically meant for Phobos, and the Phobos coding standard are spaces.

Bye,
bearophile

> Nick Sabalausky:
> > What, so that he can force his indentation size on everyone else that works on the code? Or so that using the left/right arrow keys within the indentation zone requires an unnessesaraly large number of keypresses?
> 
> It's a module theoretically meant for Phobos, and the Phobos coding standard are spaces.

Yes. Phobos follows the convention of indenting with spaces and that levels of indentation are 4 spaces. So, anything which goes into Phobos needs to follow this convention.

the only way that tabs work is if you use them consistently, which in my experience almost never happens. And pretty much everywhere that I've worked has required that spaces be used and no tabs. When people _have_ used tabs, it's been a mess. Personally, I'm completely against using tabs in source code.

Regardless, Phobos doesn't use tabs. So, whatever someone may prefer in their own code, code that they intend to get into Phobos shouldn't use tabs.

- Jonathan M Davis