Fwd: Some explanations/suggestion on plasmate

[Aaron J. Seigo]

On Thursday 28 May 2009, Diego Casella ([Po]lentino) wrote:
> On Thursday 28 May 2009, 07:34 you wrote:
> > a class declaration ). So, I was wondering if could I continue on
> > riccardo code, adding all the basical function needed ( such as
> > init,clone, pull, diff, apply, status, checkout and commit ).
>
> Maybe it's a good idea to send an email do plasma-devel so others can also
> give
> their opinions on this one. I didn't take a look on Vng so I can't argue
> here
> very much. I'm just afraid that in the end we have to reimplement a lot of
> things that are already in Vng....

i'd rather see us use something that already exists as well, be that vng or 
whatever is used in QtCreator or, and this is my personal favourite btw, the 
git plugin in kdevplatform which already has what we need implemented.

> >    1. run the git -add comand  every time a new file is created, and then

yes, new files should be instantly added.

> >    run it every x minutes, defined by user from a form named "autosave",
> > then run git -commit when the developer click on "save file" button. (
>
> very
>
> > ugly, I know )

why is this "very ugly"?

> >    2. run git -add when the user press the "save file" button, and call
>
> git
>
> >    -commit when "save project" is pressed, displaying a box for inserting
> >    informations on the commit. ( this makes more sense, but from the
> > point of view of simplicity, there are too "save something" buttons )

if we can avoid having different save buttons for different things (files vs 
projects) that'd be great. i don't see any significant advantage, given the 
goals of plasmate, to having per-file-saving.

we're not trying to build an IDE capable of housing a 1000 file project with 
50 different components, after all.

KISS.

> Hmmm...another idea would be to have an "Add File To Project" like Kile and
> other editors have.

there is no such thing as a file in the Plasma::Package that isn't part of the 
Plasma::Package, so i don't think this would do anything other than make 
another step that the user has to do and can get wrong (by forgetting)

> > A solution could be implementing the previewer as a tabbed widget, and
> > put it together with the other  editor tabs, so the coder first edit all
> > the files needed, then change to the preview tab to see the result =) Or,
> > we can add an auto show/hide feature to the dock widget, so it pops-up
> > only when needed.
>
> The preview tab may work and I agree that maybe keeping the previewer open
> all
> the time may waste screen space...

what's wrong with regular Qt DockWidgets? then you get tabbing "For free", 
albeit only on the window edges.

so you could have:

* project tree above previewer
* tabs for tree and previewer
* tree on left, previewer on right
* previewer closed (re-open when preview is requested again)
* previewer floating in own window

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090528/9d791eca/attachment.sig