[wx-dev] RFC Adding File Information to wxFrames
Stefan Csomor
on OSX we have two additional information parts in the title of a wxFrame,
for a screenshot see:
http://papernapkin.org/pastebin/resource/images/imageEntryId/2068
* first there¹s the modified state of the CONTENTS of a window (ie NOT its
position etc), this is noted in a darker dot in the red close button on the
left
* second there¹s the file path of the file storing the contents of this
window, this leads to a corresponding icon and to some additional
functionality, ie this so called proxy icon can be dragged around, it can be
command-clicked to see its entire path etc
I have implemented the functionality now for testing in docview.cpp but I
thought that it might be better to move this to a wxFrame API level, like
wxFrame::SetModified( bool )
wxFrame::SetFilename( wxString )
make it virtual and have the default implementation doing nothing
or perhaps even store the data and provide IsModified, GetFilename as well ?
are there similar capabilities on other platforms ?
Thanks for opinions and pointers
Stefan Csomor
Stefan Csomor
> SC> I have implemented the functionality now for testing in docview.cpp but I
> SC> thought that it might be better to move this to a wxFrame API level, like
> SC>
> SC> wxFrame::SetModified( bool )
> SC> wxFrame::SetFilename( wxString )
> SC>
> SC> make it virtual and have the default implementation doing nothing
> SC> or perhaps even store the data and provide IsModified, GetFilename as well
> ?
>
> From a pure OO point of view I dislike putting this into wxFrame. Not all
> frames correspond to file-oriented documents so why should they have
> methods which may have no meaning for them?
>
> OTOH not all programs using file-oriented documents use docview framework
> neither so putting it at wxDocChildFrame level wouldn't be ideal neither.
>
> So the logical conclusion would be to have an intermediate wxDocFrame
> class which would inherit from wxFrame and add the methods above. And
> wxDocChildFrame would inherit from wxDocFrame and provide implementations
> of these methods in terms of its m_childDocument. Notice that this would
> still mean that any non-docview application wanting to use these methods
> would have to implement them but I think it's actually a good thing (and
> would make these methods pure virtual in wxDocFrame to emphasize it).
yes, I thought about this as well, the thing is that there are a few
additional irks ...
- this feature also is used on not file-document based applications like
Address Book, where eg you drag a vcard of a certain entry when you drag the
proxy icon and I wanted to provide that feature for all cases
- also the inheritance differences between mdi and non mdi docviews didn't
show me an obvious solution:
the inheritance of wxDocChildFrame which derives from wxFrame and
wxDocMDIChildFrame which derives from wxMDIChildFrame don't offer a common
place to hook into it, unless we let wxMDIChildFrame derive from wxDocFrame
as well, otherwise we will have to factor this out and have a common
implementation that gets plugged into these two classes.
- ( btw the name wxDocFrame would somehow implicate the use of wxDocument,
which IMHO shouldn't be mandatory)
> SC> are there similar capabilities on other platforms ?
>
> There is nothing native AFAIK. OTOH under Windows it's pretty common to
> change the title of the frame to be "document name - program name" when a
> document is opened while the normal title is just "program name" in
> document-oriented applications. And the equivalent of "modified" flag would
> be "document name [modified] - program name".
>
> Of course, as this is not enforced nor even supported by the system, the
> convention is not followed by all programs and it varies, even among
> Microsoft own ones. So we'd need to make almost all parts customizable.
we can do that as a default generic implementation and everybody who's not
happy with it can override it ...
Thanks,
Stefan