Reply to Nick,

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

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.

On Fri, 24 Apr 2009 14:00:19 -0400, Nick Sabalausky <a@a.a> wrote:

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

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

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

There are two possible use cases: serializing (to a text-based or binary format) and formatting.

Serializing won't always fit here. For example, if you want to serialize to XML, you need to tell the serializer when you're beginning a tag and what to name it and when to end it. This might be possible with ranges, but it would be awkward. Or maybe you have different concerns when serializing in one binary format versus another. Or you're outputting JSON, and you could view something as an array of objects or as a single object -- you need to specify that.

Formatting is the other concern. This is a special case of non-hierarchical serialization, for which ranges could work.

However, formatting *has* to be general. I rarely need to override a formatting method, but I often need to access something via an interface or base class and format it. If this does not work, then toString is vastly superior. And to gain the benefits you're talking about, I have to be able to pass in different output streams.

You can get the first requirement by having a method that takes a formatting struct on Object, but then object.d depends on formatting -- this isn't a reasonable situation. object.d can at most define an interface for a formatting method:

interface OutStream { ... }
class Object
{
	...
	void print (string format, OutStream stream);
}

This is still pushing it.

An alternative is to have:
void Object.print (void delegate (...) sink);

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.

Reply to Christopher,

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

So I guess we're stuck with the no-close close button if we don't want any way to close the app in a single click.

"BCS" <ao@pathlink.com> wrote in message news:78ccfa2d3ebc18cb92e7b8abed64@news.digitalmars.com...
>
> 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.

?? Not only can I honestly say I've never had that problem, but I find the whole idea of it very strange. Are you certain that your mouse or window manager isn't just acting up?

> I guess if you really hate having it not kill the app then the program could just not /have/ a x button.
>

You've got to be kidding me, that would be just as bad. Why would I want to have a program get rid of the standard "exit" mechanism? Whever I come across an app like that, the first thing I do is open the task manager and kill it, and then immediately uninstall it.

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

In this particular case, that's exactly the same thing. It's the "close"/"exit" button. If it doesn't "close"/"exit" then it's been re-tasked. Either to "minimize to tray" or to "noop" or whatever.

Hello Nick,

>> I guess if you really hate having it not kill the app then the
>> program could just not /have/ a x button.
>> 
> You've got to be kidding me, that would be just as bad. Why would I
> want to have a program get rid of the standard "exit" mechanism?

If you basicly never want to exit it? (see below)

> Whever I come across an app like that, the first thing I do is open
> the task manager and kill it, and then immediately uninstall it.
>

I'll grant there are only very few cases where I want it, but in those cases I wouldn't have the program at all unless I wanted it running *all the time*. If I found myself killing/restarting the program more than rarely, I'd git rid of it and find one I don't have to do that with. For those apps, I basically never want to actually close them (even less often than I reboot) and on the few occasions when I do, I'm willing to do file->exit->"Yes I really do" sequence.

As an example of a program that works this way that I'll bet you don't mind: The volume control in the system tray. I'm not even sure if there /is/ a way to close it all the way.

To put it objectively: say the program take 10 sec to reload and 90% of the time (I'd bet that's low) that I click the x button, it was a mistake (bad mouse control, reflex "go way action", whatever). From that it can take 90 seconds to close the program before tuning off the x button is a net loss (as long as it's easy to figure out how to really kill it).

We may have to agree to disagree; I use a few programs where having the x button kill them would be a bad thing IMHO. You disagreeing really doesn't matter to me. 

Georg Wrede wrote:
> Jarrett Billingsley wrote:
>>> 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.

I think it's because Firefox doesn't know you're just dragging those images to a tab. For all the browser knows, you're playing a game of chess, and you're dragging a pawn to E5. In which case, it makes a lot of sense for a ghost image to follow the drag behavior.

For generalized dragdrop, I think ghosted images are a good, safe guess.

Did you know you can right-click to "Open in New Tab"?

--benji