On Fri, 24 Apr 2009 13:54:26 +0400, Nick Sabalausky <a@a.a> wrote:

> "BCS" <none@anon.com> wrote in message
> news:a6268ff50558cb92691721562e@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".
>
>

"Minimize" button usually minimizes the window to task bar.

Some applications provide an additional button alongside minimize and close that minimizes to tray (Emule and others).
Some other applications minimize to tray when you hold Shift while clicking the minimize button - Vypress chat, Download Master, Total Commander (plugin) and others. But overall - it's very inconsistent.

I personally wish that more programs adopt Shift+Minimize -> Tray behavior, it's easy to remember and easy to implement.

> 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.


AFAIK, the gmplayer GUI is deprecated. Use mplayer or smplayer. smplayer is a GUI for mplayer that surprisingly manages to use a standard GUI, and not some skinable specially-made media GUI bullshit, that plagues most media players.

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

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

Nick Sabalausky wrote:
> "Georg Wrede" <georg.wrede@iki.fi> wrote in message news:gsrrfn$kv3$1@digitalmars.com...
>> 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!
>>
> 
> Well put.
> 
>> 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.
> 
> Funny, earlier today I was just thinking very much the same thing about a video I saw a few weeks ago of Palm's WebOS (Or it might have been some clone of WebOS). Fancy moving curves and scaling icons that serve absolutely no purpose besides 1. "flash for the sake of flash" (I *hate* that!) and 2. drain the battery. Which is really sad, I used to have so much respect for Palm...But then they killed graffiti, and then replaced their PDAs with cell phones (and we never did get PDAs with hard drives, which is ridiculous, even my portable music player has a damn hard drive, which of course is one device I wouldn't even need if my PDA *had a hdd!!*), and now this WebOS garbage, sheesh...And speaking of PDAs, now Nintendo's been changing their DS from a reasonable gaming device into the world's shittiest PDA...Man, the world of software and consumer electronics really depresses me these days... 

It was different in the old days. In 1981 HP introduced the HP-12c financial calculator. Seems it's still sold, for about $60.

I'd like to see the consumer gadget introduced this year, that is still sold in 2037.

And they're built to last. I have a few HP calculators (the earliest a HP-25, I bought in 1975), and they're fiercely usable, sturdy, and definitely not cluttered with unneeded "features". I still use them, particularly the HP-28s, the HP-25, and the HP-95 (which is actually an IBM PC in palmtop size).

grauzone wrote:
>> 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.
> 
> AFAIK, the gmplayer GUI is deprecated. Use mplayer or smplayer. smplayer is a GUI for mplayer that surprisingly manages to use a standard GUI, and not some skinable specially-made media GUI bullshit, that plagues most media players.

Thanks!

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

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

Hello Nick,

> "BCS" <none@anon.com> wrote in message
> news:a6268ff50558cb92691721562e@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.

"BCS" <none@anon.com> wrote in message news:a6268ff50d58cb92d952e5b612@news.digitalmars.com...
> Hello Nick,
>
>> "BCS" <none@anon.com> wrote in message news:a6268ff50558cb92691721562e@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.