Re: dmd 2.029 release [OT]
Steven Schveighoffer wrote: On Thu, 23 Apr 2009 14:32:13 -0400, Georg Wrede georg.wr...@iki.fi wrote: I mean, who's such a nutcase that he forgets halfway in the dragging, what it is he's dragging? It might be useful if you accidentally start dragging the wrong thing, and then realize because you are dragging the wrong picture/text/etc. But my point was really: you complained that you couldn't see the target because the picture is covering it. My experience is that I can clearly see the target because the picture is translucent (I can see the target underneath the picture). My complaint was about doing stuff just because you can. The dragging was just the first gross example that crossed my mind. (I'm on a slow graphics card. Besides, it hasn't bothered me enough to start investigating. Heck, for all I know, I could configure it away.)
Re: dmd 2.029 release [OT]
Jarrett Billingsley wrote: On Thu, Apr 23, 2009 at 2:32 PM, Georg Wrede georg.wr...@iki.fi wrote: (OT: an excellent example of this It's Done Because We Noticed We Could stuff is in Firefox. When a picture is a link to another page, and you want to drag that to the tab area, the entire picture is dragged with the mouse. Now, how the hell am I supposed to hit the small tab area when the large picture covers half of my Firefox?? Sure it looks good, and the computer owner can brag to the guy in the next cubicle, etc. But there should be some obvious or useful *purpose* for dragging entire pictures where a mouse pointer would be clearer, cleaner, easier for the user, and use less computer cycles. I mean, who's such a nutcase that he forgets halfway in the dragging, what it is he's dragging? Middle-click. Yeah. But I still don't see the glamouros advantages in dragging whole pictures. And I often drag stuff to existing tabs. A good example is when browsing http://apod.nasa.gov/apod/ap090424.html where I usually end up with a dozen tabs in no time.
Re: dmd 2.029 release [OT]
Steven Schveighoffer wrote: On Thu, 23 Apr 2009 14:32:13 -0400, Georg Wrede georg.wr...@iki.fi wrote: Steven Schveighoffer wrote: On Thu, 23 Apr 2009 12:09:20 -0400, Georg Wrede georg.wr...@iki.fi So now I have to learn to remember to grab bigger pictures near some edge. And I really can't see *any* valid benefit for having to drag the picture. I'd rather have it the old way, where the mouse pointer simply changes shape, so you know you're dragging. Damn, damn...) On my system, dragging the image drags a translucent copy of the image, so I can still see where my mouse pointer is aimed. Maybe you don't have enough colors enabled on your screen? Sure it looks good, and the computer owner can brag to the guy in the next cubicle, etc. But there should be some obvious or useful *purpose* for dragging entire pictures where a mouse pointer would be clearer, cleaner, easier for the user, and use less computer cycles. I mean, who's such a nutcase that he forgets halfway in the dragging, what it is he's dragging? One thing that does annoy me is if you are doing this over a slow RDP link, the eye candy isn't worth it. I was never a huge fan of application themes. I don't mind a theme for the whole system (as long as it's simple), but I don't want iTunes to look different just because it can. I think it has been discussed before that most video editors have the slickest GUI, with real-looking knobs and led's, but the video editing part of it is buggy as hell. You're the first one to comment on the actual issue!!! :-) Those video editors, iTunes and such look like they're programmed by 12-year olds. Somewhere there should be an adult saying what not to do! I bet the guy who did this never expected that whole-picture dragging actually uses more electricity in your computer. When every Firefox user (and the others who have to implement this too, so as not to look inferior!) in the whole world drags whole pictures, the combined increase in world electric usage rises well above his day-job salary. Greenpeace ought to shoot him.
Re: dmd 2.029 release [OT]
Nick Sabalausky wrote: Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.usux6bskeav...@steves.networkengines.com... I was never a huge fan of application themes. I don't mind a theme for the whole system (as long as it's simple), but I don't want iTunes to look different just because it can. That's one of my biggest pet peeves about modern software. I can't really do the subject justice without delving into a giant pile of expletives. It took me some serious browsing before I found a non-obtrusive skin for gmplayer. And I hated to have to do that. It should have been the default. But worse still is when they decide to go and piss all over not just standard looks, but also standard behaviors. Like how the Win build of iTunes will still ignore/eat any click that brings it to the foreground. If I wanted that behavior I'd be running a Mac. That's a good thing with many *nix GUIs. You can have several overlapping windows, and even do stuff in the non-top ones. But they really should respect the target GUIs way of doing things, when porting. The absolute worst of all though is when an app (*cough* skype *cough*) decides that close and the 'close' button should mean don't close anything at all, but minimize to tray instead. That should be a firing squad offense ;) Joking aside though, any of these are guaranteed ways to make me lose any and all respect for a piece of software and its developers, especially if they're arrogant enough to provide no way to turn such things off. Yeah, the biggest motivation (next to being graphical per se) for GUIs was uniform app behavior. That way you only would need to learn the common basics, and then, ostensibly, you could use any new app right off the bat. (In the bad old days, you really had to learn to use every app, one at a time.)
Re: dmd 2.029 release [OT]
BCS n...@anon.com wrote in message news:a6268ff50558cb926917215...@news.digitalmars.com... Hello Christopher, Nick Sabalausky wrote: The absolute worst of all though is when an app (*cough* skype *cough*) decides that close and the 'close' button should mean don't close anything at all, but minimize to tray instead. That should be a firing squad offense ;) I'd be killing my IM client constantly if not for that feature. I pretty much expect it of any application that's meant to be running for a long time and only rarely needing user interaction (such as a bittorrent client). yah, for some programs you rarely want to close the program but often want to close the UI. That's called Minimize.
Re: dmd 2.029 release
grauzone wrote:
void streamOut(T, R)(T object, R range)
{
foreach(x; a) range.put(x);
range.put(b);
range.put(c);
}
So, um... what is a b c and T object?
In my opinion, this is a confusing example. I believe it was meant to be:
void streamOut(T, R)(T object, R range)
{
foreach(x; object.a) range.put(x);
range.put(object.b);
range.put(object.c);
}
So, streamOut is a free function, which it normally would not be. Now, consider
this:
struct foo {
int[] a;
bool b;
char c;
void streamOut(R)(R range) {
foreach(x; a) range.put(x);
range.put(b);
range.put(c);
}
}
I believe this is what you'd normally do.
Do note that I might have misinterpreted it all, as Andrei's code would not do
what I have outlined above, I only feel it makes the most sense.
--
Simen
Re: dmd 2.029 release
Simen Kjaeraas wrote:
grauzone wrote:
void streamOut(T, R)(T object, R range)
{
foreach(x; a) range.put(x);
range.put(b);
range.put(c);
}
So, um... what is a b c and T object?
In my opinion, this is a confusing example. I believe it was meant to be:
void streamOut(T, R)(T object, R range)
{
foreach(x; object.a) range.put(x);
range.put(object.b);
range.put(object.c);
}
So, streamOut is a free function, which it normally would not be. Now,
consider this:
struct foo {
int[] a;
bool b;
char c;
void streamOut(R)(R range) {
foreach(x; a) range.put(x);
range.put(b);
range.put(c);
}
}
I believe this is what you'd normally do.
Do note that I might have misinterpreted it all, as Andrei's code would
not do what I have outlined above, I only feel it makes the most sense.
Yeah OK, but what about virtual functions? Not having it virtual is a
real disadvantage, because subclass-parts aren't automatically dumped.
What exactly is R, and why is it simpler than a Sink delegate? A Sink
delegate is as simple as it gets, and what else than a string do you
want to output? (Hint: this is probably not supposed to be a
serialization framework.)
One thing that I could imagine that put() automatically takes care of
formatting various data types into a string. Okay, where can I pass
format specifiers? What if put() can't deal with the type? Or does it
call std.string.format() anyway? Then why the indirection through the
string? Why not call format() directly? (Yes, format() needs to be able
to output using a sink instead of returning a string.)
Oh by the way, unlike a weird template, sink works with virtual methods,
too.
I have the impression Andrei wants to cast everything into ranges
instead of adhering to KISS.
--
Simen
Re: dmd 2.029 release
Andrei Alexandrescu wrote: grauzone wrote: Simen Kjaeraas wrote: Do note that I might have misinterpreted it all, as Andrei's code would not do what I have outlined above, I only feel it makes the most sense. Yeah OK, but what about virtual functions? Not having it virtual is a real disadvantage, because subclass-parts aren't automatically dumped. Streaming out is a virtual function that takes a classic interface object. (I explained that in two posts.) There were a lot of posts in this thread. From what I've gathered, what you said wasn't really concrete. Not as concrete as the sink proposals. What exactly is R, and why is it simpler than a Sink delegate? A Sink delegate is as simple as it gets, and what else than a string do you want to output? (Hint: this is probably not supposed to be a serialization framework.) It is simpler than a Sink delegate because the delegate is not simple; it's simplistic. You can't use std.algorithm with a delegate, it only accepts one type (meaning it is very inefficient if you have multiple types to output) - it's essentially a non-design. At some point, you need to format it to a string anyway. And it's probably not favorable to move that code into some deeply buried library code, because then you don't have full control over formatting. Anyway, I don't quite understand what you want to do. We were talking abou improving toString, right? One thing that I could imagine that put() automatically takes care of formatting various data types into a string. Okay, where can I pass format specifiers? What if put() can't deal with the type? Or does it call std.string.format() anyway? Then why the indirection through the string? Why not call format() directly? (Yes, format() needs to be able to output using a sink instead of returning a string.) I'd spend more time on explaining that but I fear you want more to convince yourself and others that output streams are no good and that your non-design is simpler, than actually getting answers to your questions. It's not my design, and I didn't even come up with that proposal. Come on, I know my tone and my posts is bitchy as hell, but flaming is not really what I'm up to. Oh by the way, unlike a weird template, sink works with virtual methods, too. I have the impression Andrei wants to cast everything into ranges instead of adhering to KISS. I want to adhere to KISS, and therefore I want to support output ranges with e.g. strings and files. If you don't take the time to look at ranges as you yourself said, then why do you spend time commenting on them? Shouldn't things go the other way? Oh, I look at the Phobos docs as it seems necessary. But I still might not know to the fullest how the pieces fit together and so on. Andrei
Re: dmd 2.029 release
grauzone wrote: Simen Kjaeraas wrote: Do note that I might have misinterpreted it all, as Andrei's code would not do what I have outlined above, I only feel it makes the most sense. Yeah OK, but what about virtual functions? Not having it virtual is a real disadvantage, because subclass-parts aren't automatically dumped. Streaming out is a virtual function that takes a classic interface object. (I explained that in two posts.) What exactly is R, and why is it simpler than a Sink delegate? A Sink delegate is as simple as it gets, and what else than a string do you want to output? (Hint: this is probably not supposed to be a serialization framework.) It is simpler than a Sink delegate because the delegate is not simple; it's simplistic. You can't use std.algorithm with a delegate, it only accepts one type (meaning it is very inefficient if you have multiple types to output) - it's essentially a non-design. One thing that I could imagine that put() automatically takes care of formatting various data types into a string. Okay, where can I pass format specifiers? What if put() can't deal with the type? Or does it call std.string.format() anyway? Then why the indirection through the string? Why not call format() directly? (Yes, format() needs to be able to output using a sink instead of returning a string.) I'd spend more time on explaining that but I fear you want more to convince yourself and others that output streams are no good and that your non-design is simpler, than actually getting answers to your questions. Oh by the way, unlike a weird template, sink works with virtual methods, too. I have the impression Andrei wants to cast everything into ranges instead of adhering to KISS. I want to adhere to KISS, and therefore I want to support output ranges with e.g. strings and files. If you don't take the time to look at ranges as you yourself said, then why do you spend time commenting on them? Shouldn't things go the other way? Andrei
Re: dmd 2.029 release [OT]
Reply to Nick, BCS n...@anon.com wrote in message news:a6268ff50d58cb92d952e5b...@news.digitalmars.com... Hello Nick, BCS n...@anon.com wrote in message news:a6268ff50558cb926917215...@news.digitalmars.com... yah, for some programs you rarely want to close the program but often want to close the UI. That's called Minimize. It can be, OTOH I might want the UI process killed without killing the main program. Another point is the other side of the assertion, you rarely want to close the program as in 90% of the time even when I hit the x button, I don't actually want to close the program. The whole point of the 'x' button is the close the program. Always has been. If I didn't want to close the program, I wouldn't push it. Are you saying you never make mistakes? There are program out there that 90% of the time when I hit the x button it was a mistake and in that cases I think it to be a good design to work around it. I guess if you really hate having it not kill the app then the program could just not /have/ a x button. If you want to hide/kill the UI without closing the program, that's minimize. True, minimizing to the taskbar doesn't kill the UI process/thread (assuming it even is a separate process/thread), but in the rare cases where the distinction of UI process running/killed actually matters, the program can still do that through a minimize to tray. And while neither minimize nor close truly mean minimize to tray, clearly minimize is FAR closer in both wording and behavior. Any way you look at it, having a close button that doesn't close the app is like having a cancel button that prints, or a save button that plays music. Your missing my point. I don't want to re-task the button but make it not do something that most of the time is not what I want.
Re: dmd 2.029 release [OT]
On Fri, 24 Apr 2009 14:00:19 -0400, Nick Sabalausky a...@a.a wrote: BCS n...@anon.com wrote in message news:a6268ff50d58cb92d952e5b...@news.digitalmars.com... Hello Nick, BCS n...@anon.com wrote in message news:a6268ff50558cb926917215...@news.digitalmars.com... yah, for some programs you rarely want to close the program but often want to close the UI. That's called Minimize. It can be, OTOH I might want the UI process killed without killing the main program. Another point is the other side of the assertion, you rarely want to close the program as in 90% of the time even when I hit the x button, I don't actually want to close the program. The whole point of the 'x' button is the close the program. Always has been. If I didn't want to close the program, I wouldn't push it. If you want to hide/kill the UI without closing the program, that's minimize. True, minimizing to the taskbar doesn't kill the UI process/thread (assuming it even is a separate process/thread), but in the rare cases where the distinction of UI process running/killed actually matters, the program can still do that through a minimize to tray. And while neither minimize nor close truly mean minimize to tray, clearly minimize is FAR closer in both wording and behavior. Any way you look at it, having a close button that doesn't close the app is like having a cancel button that prints, or a save button that plays music. Yahoo messenger's X button behavior: click on it - Although the main window has been closed, Yahoo! Messenger will continue to run in the system tray... With a checkbox that says Show this message in the future. That's perfect for me. YM also has an option to automatically remove the taskbar button when minimized (so minimized does the behavior you want it to do). -Steve
Re: dmd 2.029 release [OT]
BCS wrote: I guess if you really hate having it not kill the app then the program could just not /have/ a x button. Your window manager does not support such windows.
Web-GMUI 0.1.2 released
Web-GMUI is a multi client / multi gui web interface that can connect to MLDonkey/aMule/rTorrent/Transmission and giFT. The new version contains a lot of bug fixes. An Italian translation was also added. http://web-gmui.sourceforge.net
RangeExtra 10^-20
RangeExtra version 10^-20 is officially out. It consists of a small and hopefully growing number of ranges that didn't make it into the new Phobos that I've gotten working reasonably well and I feel eventually belong in Phobos. Docs / What's there: http://cis.jhu.edu/~dsimcha/rangeextra.html Code: http://dsource.org/projects/scrapple/browser/trunk/rangeextra/rangeextra.d License: Dual licensed, Phobos license or BSD (Tango style).
