basket-devel — Discution between the developers, translators...

Re: [Basket-devel] c++0x

[Matt R. <ma...@kd...>]

On Aug 25, 2011 9:46 PM, "ilusionoflife" <ill...@gm...>
wrote:
>
> What do you think about it? Should we use it?
> I think yes, because we already use POSIX-only features, such as fork and
> popen. Then compiler is nearly definitely gcc, so why not take advantage
of
> things like for(auto &key, container).
> Now i am working on refactoring different classes and find, that new
features
> will simplify code. Your opinions?
>
> Best regards, illusionoflife
>

To echo Robert here, there's not really anything in C++11 that we really
need to be using. Your idea isn't bad. We're just not ready for that yet.
:-)

--
Matt

Re: [Basket-devel] c++0x

[Robert M. <ro...@na...>]

We actually do have users on both Windows and Mac OS X.  I'd like to hold off 
on c++11 for now until it becomes more widely adopted or we have a clear need 
for the features -- most of the new features can be implemented just as easily 
using Qt features (like QWeakPointer) for now.

On Thursday, August 25, 2011 10:44:19 PM ilusionoflife wrote:
> What do you think about it? Should we use it?
> I think yes, because we already use POSIX-only features, such as fork and
> popen. Then compiler is nearly definitely gcc, so why not take advantage of
> things like for(auto &key, container).
> Now i am working on refactoring different classes and find, that new
> features will simplify code. Your opinions?
> 
> Best regards, illusionoflife
> 
> ---------------------------------------------------------------------------
> --- EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Basket-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basket-devel

Re: [Basket-devel] QGraphicsViews port

[Kelvie W. <ke...@ie...>]

2011/8/22 Lionel Petit <lio...@gm...>:
> Hi,
>
>  Which part of KDE API did you refer to ?
>  AFAIK, KDE doesn't provide or reimplement a framework like qgraphicsview.
>
>  With Qt5 plans, all Qt3Support will disappear and, if we want Basket to be
> still here, we have to remove this old dependencies.
>  Removing the use of Qt3 now will allow us to have a working Basket either
> with Qt4 or Qt5 (with few efforts I hope).
>  That way, we could have more time to think about how to gracefully
> integrate Basket in Qt/KDE 5 (I think is too early to plan that but I could
> be wrong).
>
>  Another option would be to wait Qt/KDE 5 API design to see what we could do
> with the risk to have a period without Basket.
>
>  And there are probably other options, let me know.
>
> Regards,
>
> Lionel

Hello Lionel,

Thank you for the work. Going forward, we have to get rid of KDE/Qt3
support somehow.  I had imagined (since Qt Quick came out) that some
form of QML would replace QGraphicsView for this task, but had not
been motivated to rewrite it.

The line editor had always been kind of wonky since we ported it to
KDE4, anyway, and this is a small step forward to ensuring Basket
stays alive... even though I haven't touched the source in a couple of
years.

-- 
Kelvie Wong

[Basket-devel] c++0x

[ilusionoflife <ill...@gm...>]

What do you think about it? Should we use it?
I think yes, because we already use POSIX-only features, such as fork and 
popen. Then compiler is nearly definitely gcc, so why not take advantage of 
things like for(auto &key, container).
Now i am working on refactoring different classes and find, that new features 
will simplify code. Your opinions?

Best regards, illusionoflife

Re: [Basket-devel] QGraphicsViews port

[Lionel P. <lio...@gm...>]

2011/8/15 ilusionoflife <ill...@gm...>

> В сообщении от 15 августа 2011 20:57:39 автор Lionel Petit написал:
> > Hi,
> >
> > I start porting Basket to QGraphicsView framework to remove one of the
> > last KDE3 dependencies.
> >
> > There is still a lot of work to do.
> > You could find a first draft in the qgraphicsview_port branch of my
> > git repository :
> >   gi...@gi...:~ptiyo/basket/ptiyo-basket.git
> >
> > The major part of this update is :
> > - BasketView is renamed BasketScene and inherits QGraphicsScene.
> > - Note and note contents use QGraphicsItem to draw themselves.
> > - NoteEditor provides QGraphicsItem when the editor is inline.
> >
> > At this step, this version works but adjusments are needed :
> > - folding/unfolding animations have been removed,
> > - when you fold/unfold a group note in a column, sometimes the column
> > is slightly shifted
> > - the inline text editor has some strange behaviour when you add multiple
> > lines, - ...
> >
> > In my opinion, this migration is necessary for the future of Basket.
> > But, before going further, I would like to know if you share this
> > point of view and if there is  people interested to work at this task.
> >
> > Regards,
> >
> > Lionel
> >
> >
> ---------------------------------------------------------------------------
> > --- uberSVN's rich system and user administration capabilities and model
> > configuration take the hassle out of deploying and managing Subversion
> and
> > the tools developers use with it. Learn more about uberSVN and get a free
> > download at:  http://p.sf.net/sfu/wandisco-dev2dev
> > _______________________________________________
> > Basket-devel mailing list
> > Bas...@li...
> > https://lists.sourceforge.net/lists/listinfo/basket-devel
> I am not expirienced in team programming, but still.
> I think its a very good intention to remove last Qt3 parts, but i am afraid
> that its bad idea to inherit Qt classes, omiting KDE layer: Qt5 coming, and
> QWidget family will be unmaintained. Maybe we should rely on KDE API some
> way
> and let them solve that problems? Just imho.
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Basket-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basket-devel



Hi,

 Which part of KDE API did you refer to ?
 AFAIK, KDE doesn't provide or reimplement a framework like qgraphicsview.

 With Qt5 plans, all Qt3Support will disappear and, if we want Basket to be
still here, we have to remove this old dependencies.
 Removing the use of Qt3 now will allow us to have a working Basket either
with Qt4 or Qt5 (with few efforts I hope).
 That way, we could have more time to think about how to gracefully
integrate Basket in Qt/KDE 5 (I think is too early to plan that but I could
be wrong).

 Another option would be to wait Qt/KDE 5 API design to see what we could do
with the risk to have a period without Basket.

 And there are probably other options, let me know.

Regards,

Lionel

Re: [Basket-devel] QGraphicsViews port

[ilusionoflife <ill...@gm...>]

В сообщении от 15 августа 2011 20:57:39 автор Lionel Petit написал:
> Hi,
> 
> I start porting Basket to QGraphicsView framework to remove one of the
> last KDE3 dependencies.
> 
> There is still a lot of work to do.
> You could find a first draft in the qgraphicsview_port branch of my
> git repository :
>   gi...@gi...:~ptiyo/basket/ptiyo-basket.git
> 
> The major part of this update is :
> - BasketView is renamed BasketScene and inherits QGraphicsScene.
> - Note and note contents use QGraphicsItem to draw themselves.
> - NoteEditor provides QGraphicsItem when the editor is inline.
> 
> At this step, this version works but adjusments are needed :
> - folding/unfolding animations have been removed,
> - when you fold/unfold a group note in a column, sometimes the column
> is slightly shifted
> - the inline text editor has some strange behaviour when you add multiple
> lines, - ...
> 
> In my opinion, this migration is necessary for the future of Basket.
> But, before going further, I would like to know if you share this
> point of view and if there is  people interested to work at this task.
> 
> Regards,
> 
> Lionel
> 
> ---------------------------------------------------------------------------
> --- uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Basket-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basket-devel
I am not expirienced in team programming, but still.
I think its a very good intention to remove last Qt3 parts, but i am afraid 
that its bad idea to inherit Qt classes, omiting KDE layer: Qt5 coming, and 
QWidget family will be unmaintained. Maybe we should rely on KDE API some way 
and let them solve that problems? Just imho.

[Basket-devel] QGraphicsViews port

[Lionel P. <lio...@gm...>]

Hi,

I start porting Basket to QGraphicsView framework to remove one of the
last KDE3 dependencies.

There is still a lot of work to do.
You could find a first draft in the qgraphicsview_port branch of my
git repository :
  gi...@gi...:~ptiyo/basket/ptiyo-basket.git

The major part of this update is :
- BasketView is renamed BasketScene and inherits QGraphicsScene.
- Note and note contents use QGraphicsItem to draw themselves.
- NoteEditor provides QGraphicsItem when the editor is inline.

At this step, this version works but adjusments are needed :
- folding/unfolding animations have been removed,
- when you fold/unfold a group note in a column, sometimes the column
is slightly shifted
- the inline text editor has some strange behaviour when you add multiple lines,
- ...

In my opinion, this migration is necessary for the future of Basket.
But, before going further, I would like to know if you share this
point of view and if there is  people interested to work at this task.

Regards,

Lionel

[Basket-devel] A fix and a change (Merge request)

[Brian M. <bc...@gm...>]

Hi,

Seeing the other email today prompted me to submit these 2 items I had done
earlier this month.

-Fix a bug that was causing embedded cross references to turn everything in
the paragraph, after the cross reference, into a link.
-Changed the layout of the Basket Properties dialog to fit on smaller screen
devices. in so doing I converted it to use a .ui file.

As I'm prepping the merge request it looks like there are other older items
that haven't been merged... Which is odd because I thought I had already
submitted them. For reference there are 2 b.k.o items to check off, a couple
of minor ui adjustments, 3 bug fixes, a crash fix, and a feature added.

Thanks,
Brian

Re: [Basket-devel] How to contribut to Basket?

[Suchitra S <su_...@ya...>]

Matt,

The code change has been submitted and merge request is created in basket 
queue.  
Could you help me with tool recommentaion or conversion steps for converting 
Word/PDF to docbook?

Regards
Suchitra


Pplease consider the environment before printing this email




________________________________
From: Matt Rogers <ma...@kd...>
To: Suchitra S <su_...@ya...>
Cc: bas...@li...
Sent: Sat, July 2, 2011 10:40:38 PM
Subject: Re: [Basket-devel] How to contribut to Basket?



On Jul 1, 2011 2:22 PM, "Suchitra S" <su_...@ya...> wrote:
>
> Matt,
>  
> We have committed the code change in git and also attached user guide under 
>"src" folder in basket.
>  
Where at? I don't see a merge request in the basket queue for this.
> Let us know if anything else needs to be done.
> 
Would it be possible for you to integrate the content of the PDF into the 
documentation for basket as do book directly?
Thanks
--
Matt
> Regards
> Suchitra
>  
>
>
> ________________________________
> From: Matt Rogers <ma...@kd...>
> To: Suchitra S <su_...@ya...>
> Cc: bas...@li...
> Sent: Thu, June 30, 2011 12:34:48 PM
> Subject: Re: [Basket-devel] How to contribut to Basket?
>
>
> On Jun 30, 2011 10:21 AM, "Suchitra S" <su_...@ya...> wrote:
> >
> > Hello,
> >  
> > We recently started using Basket and are using custom code to import the 
>contents from OneNote to Basket and wanted to contribute to the community.
> > Should we submit the code to Git directly as per ReadMe document or send as 
>an attachment to the distribution list?
> >  
> > Please let us know.
> >  
> > Regards
> > Suchitra
> >  
> > P please consider the environment before printing this email
> >
>
> Please create a merge request on gitorious to submit the code.
> --
> Matt

Re: [Basket-devel] How to contribut to Basket?

[Matt R. <ma...@kd...>]

On Jul 1, 2011 2:22 PM, "Suchitra S" <su_...@ya...> wrote:
>
> Matt,
>
> We have committed the code change in git and also attached user guide
under "src" folder in basket.
>

Where at? I don't see a merge request in the basket queue for this.

> Let us know if anything else needs to be done.
>

Would it be possible for you to integrate the content of the PDF into the
documentation for basket as do book directly?

Thanks
--
Matt

> Regards
> Suchitra
>

>
>
> ________________________________
> From: Matt Rogers <ma...@kd...>
> To: Suchitra S <su_...@ya...>
> Cc: bas...@li...
> Sent: Thu, June 30, 2011 12:34:48 PM
> Subject: Re: [Basket-devel] How to contribut to Basket?
>
>
> On Jun 30, 2011 10:21 AM, "Suchitra S" <su_...@ya...> wrote:
> >
> > Hello,
> >
> > We recently started using Basket and are using custom code to import the
contents from OneNote to Basket and wanted to contribute to the community.
> > Should we submit the code to Git directly as per ReadMe document or send
as an attachment to the distribution list?
> >
> > Please let us know.
> >
> > Regards
> > Suchitra
> >
> > P please consider the environment before printing this email
> >
>
> Please create a merge request on gitorious to submit the code.
> --
> Matt

Re: [Basket-devel] How to contribut to Basket?

[Suchitra S <su_...@ya...>]

Thanks Matt.  Will submit the code soon.

Regards
Suchitra
 
Pplease consider the environment before printing this email




________________________________
From: Matt Rogers <ma...@kd...>
To: Suchitra S <su_...@ya...>
Cc: bas...@li...
Sent: Thu, June 30, 2011 12:34:48 PM
Subject: Re: [Basket-devel] How to contribut to Basket?



On Jun 30, 2011 10:21 AM, "Suchitra S" <su_...@ya...> wrote:
>
> Hello,
>  
> We recently started using Basket and are using custom code to import the 
>contents from OneNote to Basket and wanted to contribute to the community.
> Should we submit the code to Git directly as per ReadMe document or send as an 
>attachment to the distribution list?
>  
> Please let us know.
>  
> Regards
> Suchitra
>  
> P please consider the environment before printing this email
>
Please create a merge request on gitorious to submit the code.
--
Matt

Re: [Basket-devel] How to contribut to Basket?

[Matt R. <ma...@kd...>]

On Jun 30, 2011 10:21 AM, "Suchitra S" <su_...@ya...> wrote:
>
> Hello,
>
> We recently started using Basket and are using custom code to import the
contents from OneNote to Basket and wanted to contribute to the community.
> Should we submit the code to Git directly as per ReadMe document or send
as an attachment to the distribution list?
>
> Please let us know.
>
> Regards
> Suchitra
>
> P please consider the environment before printing this email
>

Please create a merge request on gitorious to submit the code.
--
Matt

[Basket-devel] How to contribut to Basket?

[Suchitra S <su_...@ya...>]

Hello,

We recently started using Basket and are using custom code to import the 
contents from OneNote to Basket and wanted to contribute to the community.
Should we submit the code to Git directly as per ReadMe document or send as an 
attachment to the distribution list?

Please let us know.

Regards
Suchitra
 
Pplease consider the environment before printing this email

Re: [Basket-devel] Help needed for releasing Basket 2.0

[Matt R. <ma...@kd...>]

On Sun, Apr 10, 2011 at 4:32 AM, Riyad Preukschas
<ri...@in...> wrote:
> On 04/09/2011 05:26 AM, Matt Rogers wrote:
>> Hi,
>>
>> I've tagged Basket 2.0 in the git repository several weeks ago. Due to
>> the lack of movement, I feel like it's time to get a new release out
>> there.
>>
>> However, I simply don't have the time to put together release notes,
>> etc. regarding the release. The most I can do is post the tarballs,
>> update the freshmeat.net entry and the website, and then make a little
>> blurb about it in my blog.
>>
>> Anybody care to help out with release notes?
>
> What happened to my email about my website work titled "Website:
> contribute and contact pages reworked"?
>
> It should be in the moderation queue.
>

I don't have access to the moderation queue, so I can't check to see
if it's still there. Feel free to send it to me directly.

> Other immediate steps for the website would be:
> * Check all links are working
> * Update all the screenshots with new ones from Basket 2.0
> * Check and update the feature list
> * Create/update the release announcement and changelog
>
> That should be enough to satisfy anyone who would be interested in
> downloading/packaging etc.
>
>
> Regards,
>        Riyad
>

Have you done this already in your clone? If so, please submit a merge
request, and I will integrate it and push it to the website ASAP.

Thanks
--
Matt

Re: [Basket-devel] Help needed for releasing Basket 2.0

[Riyad P. <ri...@in...>]

On 04/09/2011 05:26 AM, Matt Rogers wrote:
> Hi,
>
> I've tagged Basket 2.0 in the git repository several weeks ago. Due to
> the lack of movement, I feel like it's time to get a new release out
> there.
>
> However, I simply don't have the time to put together release notes,
> etc. regarding the release. The most I can do is post the tarballs,
> update the freshmeat.net entry and the website, and then make a little
> blurb about it in my blog.
>
> Anybody care to help out with release notes?

What happened to my email about my website work titled "Website: 
contribute and contact pages reworked"?

It should be in the moderation queue.

Other immediate steps for the website would be:
* Check all links are working
* Update all the screenshots with new ones from Basket 2.0
* Check and update the feature list
* Create/update the release announcement and changelog

That should be enough to satisfy anyone who would be interested in 
downloading/packaging etc.


Regards,
	Riyad

Re: [Basket-devel] Don't Forget Trinity (KDE 3.5.13) and other KDE3/Qt3 distros in code decisions

[Matt R. <ma...@kd...>]

On Thu, Apr 7, 2011 at 9:16 AM, David C. Rankin
<dra...@su...> wrote:
> Guys,
>
>   Just dropping a note to make sure you don't forget that KDE3 is very much
> alive and Trinity is actively developed. Projects like LibreOffice, who in the
> past have disabled many of the KDE3/Qt3 hooks, are now re-enabling the KDE3
> interfaces in the code to support Trinity and the distributions that continue to
> package KDE3 (openSUSE, etc..)
>
>   While Trinity is moving to CMake and Qt4 for KDE3, for the time being it is
> still Qt3 based. See, eg:
>
>   http://www.trinitydesktop.org/
>   https://wiki.archlinux.org/index.php/Trinity
>
>   So if you run into a situation in the code where you're thinking "should we
> just gut this Qt3 stuff?", please remember that there are a number of active
> projects and distributions that continue to rely on basket working on Qt3.
>
>   You might already know all of this, but I thought I would drop a line to make
> sure :p
>
>   Keep up the great work!
>
>   And on the window thread/patches, I think that after basket2 settles, it will
> be worth looking at developing a redistributable for XP-7. I'm not on windows
> much except for accounting and tax, but when I'm there, I always end up thinking
> "damn, it would sure be nice to have my baskets here."  Who knows -- could be
> the next killer app :)
>

I wouldn't have any problems with this happening, but somebody has to
be willing to do the work to continue to support this.

I'm (personally) not willing to continue to support KDE 3, so you'll
likely see me remove places that explicitly mention KDE 3 and the KDE
3 way of doing things. However, if someone is interested in this, they
can step forward, and we can work a proper solution. :)

Thanks
--
Matt

[Basket-devel] Help needed for releasing Basket 2.0

[Matt R. <ma...@kd...>]

Hi,

I've tagged Basket 2.0 in the git repository several weeks ago. Due to
the lack of movement, I feel like it's time to get a new release out
there.

However, I simply don't have the time to put together release notes,
etc. regarding the release. The most I can do is post the tarballs,
update the freshmeat.net entry and the website, and then make a little
blurb about it in my blog.

Anybody care to help out with release notes?

Thanks,
Matt

Re: [Basket-devel] How hard would enabling network/remote basket storage development be?

[rom1dep <ro...@gm...>]

2011/4/7 Dr. Robert Marmorstein <ro...@na...>

> The "right" solution is to integrate basket with Akonadi so that the
> storage
> of notes, baskets, tags, and so forth can be done using any of the modules
> Akonadi supports (an IMAP server, flat files, etc).
>
> We've had different people start looking at that, including one GSoC
> proposal
> (that didn't get accepted -- it would have if kdepim got one more slot...),
> but it's a difficult task.  The way the source code is organized right now
> makes
> it hard to get all the pieces (tags, emblems, etc) together in one place
> and
> represent them as items and collections.
>
> It's something I've been meaning to play with for a long time, but I
> haven't
> had much development time recently -- and most of the time I've had, I am
> spending fixing bugs on the software I use on a daily basis (such as
>  koffice)
> rather than basket (which my wife uses).
>
> Robert
>
> On Thursday, April 07, 2011 09:01:57 AM Scott Stubbs wrote:
> > >   Like any good basket user with multiple boxes in multiple locations,
> I
> > > religiously 'backup' my baskets, put the gzip file in a location I can
> > > get to it via rsync or http to copy it to work/etc.. and then 'restore'
> > > my basket store on multiple machines. It just seems to me that in this
> > > day and age, I should be able to put the basket storage on a server
> > > with local and remote access so I could just read/write to the network
> > > basket location without having to 'backup' and 'restore' on each box I
> > > have basket installed on.
> > >
> > >   I don't know how difficult something like this is to implement, but
> > > with fish://, sftp:// or just plain old ftp://, it seems like this
> > > should be doable.
> >
> > It does seem doable but it's not a straight forward task to do it
> > right. Remember basket isn't set up for having multiple access at the
> > same data store.
> >
> > > Anybody ever looked into something like this?
> >
> > Kelvie has a published basket of what he has. And recently (when I had
> > a lot more time) I was looking into it. I never wrote any code but I
> > was playing around with different designs on paper.
> >
> > My solution feels hackish, even though I've removed the requirement to
> > have it file based (so I didn't do any abstraction). But I like the
> > file aspect. My next step was to discuss on here what we wanted out of
> > it.
> >
> > So I started with the simple common use case where people have 2
> > machines connected at all times. One desktop and one laptop. Since
> > they only use at a time and they are connected to the net, syncing is
> > straight forward. Whether we want a centralized (at one of the 2
> > machines, or a third being a server).
> >
> > Next was the fact that thinking into the future, when I get a smart
> > phone I'd really like to have access to my baskets. Not really huge
> > idea change, since for the most part the phone is always connected
> > too. It wouldn't really need a local store even. Although if you get a
> > bad signal you don't have your baskets isn't ideal to me.
> >
> > Next was back to the laptop. It's a laptop so I'm going to disconnect
> > it sometimes. Again, local store is really needed. But then I do some
> > updates on there. And then I might do a change something on the
> > desktop before I resync them again. And that's where the issue comes
> > in: Off line editing.
> >
> > Now Kelvie has mentioned the git model. And I think that is a nice way
> > of going. But I'm not sure how we'd want to implement it. If we just
> > take the idea and not the code (we could use a DB as a backend), I'm
> > concerned that we'll get a huge growing history. I'm not sure what
> > that would do for speed and size, but perhaps we could have a cut off,
> > where all things are to be at a known sync point.
> >
> > Another thing is that at what level would one do the git diffs. I mean
> > is it the entire basket change or would it be each property of the
> > basket (mostly an issue an creation, not in modification).
> >
> > And with encrypted baskets do we really want each iteration in the
> > history? What if we encrypt of decrypt something.
> >
> > We could try to stick with the git code as a back end, lets us use the
> > files we have now. But again the encryption issue, and then merging as
> > well.
> >
> > Which brings me back to merging. What if there is a conflict? Do we
> > give an option to do an easy merge (as in take the note with the most
> > recent time) so to help out new users.
> >
> > Also, I'm not sure how tide in this could be with the undo/redo aspect
> > because of the encrypt/decrypt problem.
> >
> > Also, what if someone wanted to use it across an office, what about
> > locking the notes during edits. Now I'm now sure how serious this
> > issue is, because a wiki may be more useful in that case. But maybe we
> > could have a read only setting, so only one machine can change a
> > basket. I'm just trying to see how flexible if we have to rewrite a
> > lot.
> >
> > Oh and of course we'd need to have encryption on the syncing,
> > especially in the smart phone case. Oh and I'd just like to throw out
> > there that QT with MySql doesn't quite have SSL. There's a patch (I
> > haven't tried it) but it's been around for a while and hasn't been
> > included yet.
> >
> > Oh, and for a key my idea was just to sha the creation time, user, and
> > host name altogether. to ensure uniqueness.
> >
> > I think I wrote all my issues. Everything should be paragraph
> > separated so that it's easier to discuss. When I get time to make a
> > proper sql schema I'll send that out. For a timeline, I'm not thinking
> > soon. A solid beta within 2 years, although that's calculated with me
> > just solely writing code, which I hope won't happen.
> >
> > Scott
> >
> >
> ----------------------------------------------------------------------------
> > -- Xperia(TM) PLAY
> > It's a major breakthrough. An authentic gaming
> > smartphone on the nation's most reliable network.
> > And it wants your games.
> > http://p.sf.net/sfu/verizon-sfdev
> > _______________________________________________
> > Basket-devel mailing list
> > Bas...@li...
> > https://lists.sourceforge.net/lists/listinfo/basket-devel
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Basket-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basket-devel
>

Yeah, this is a feature I would very appreciate too :)

I have been thinking on such things for personal projects by the past, I see
two kind of models :

o First, we can consider the basket as being static.
I mean, we need to commit changes once (when the user saves or when he
closes the app for example). In this case, the proper way to get things done
is -I think- to adopt the versionning approach (SVN or git for example) : we
push changes to a remote repo.
+ : this way we can easily manage conflicts, multiple files, asynchronous
access on different files : "synchronized-basket" is finally only a frontend
for an underlying techno (git/ssh/hg/...) to easily handle commit conflicts.
- : we lose the encrypted functionality

o We can consider a basket as a moving object
Typically, http://piratepad.net/rxnwDk9tll
, a place where multiple users can write at the same time, it's the "Google
Docs" paradigm, see ref1
+ : there is no more conflict, plus the encrypted functionnality can be kept
(SSL + a real time decoding/encoding layer)
- : how to make it real ?! → sounds huge
One response is the wave protocol : http://www.waveprotocol.org/
This protocol defines such a real time editing approach
Problems are :
- : for now it's only a draft (just try to built it and run locally... :(  )
- : the server part is written in java, it's like maintaining two different
projects for you :(
- : waveprotocol is meant to grow fast, keeping it compatible with basket
could be a killing task

In parallel to that, we have to consider the server side : what's easier btw
a svn server, a wave server or a personal ftp server ?
Unquestionably it's the FTP one... and FTP is just not compatible with any
two approachs I described before without reinventing the wheel (= moving the
remote code for managing commits, asynchronous access, conflicts directly in
the basket app)

So the solution of this big equation is somewhere between
- the flexibility we want
- how many developers are there
- what the user has as a server


If we eliminate the asynchronous access, a ftp server with folders,
textfiles and lockfiles is far enough to me :)
plus, this would be compatible with a dropbox server with nearly no more
effort, and it's very a good point at a time where people don't care about
those strange F,T and P letters, and anyway don't want to.

That was my two cents :)

Romain.

def1: http://en.wikipedia.org/wiki/Collaborative_real-time_editor

Re: [Basket-devel] How hard would enabling network/remote basket storage development be?

[Dr. R. M. <ro...@na...>]

The "right" solution is to integrate basket with Akonadi so that the storage 
of notes, baskets, tags, and so forth can be done using any of the modules 
Akonadi supports (an IMAP server, flat files, etc).  

We've had different people start looking at that, including one GSoC proposal 
(that didn't get accepted -- it would have if kdepim got one more slot...), 
but it's a difficult task.  The way the source code is organized right now makes 
it hard to get all the pieces (tags, emblems, etc) together in one place and 
represent them as items and collections.

It's something I've been meaning to play with for a long time, but I haven't 
had much development time recently -- and most of the time I've had, I am 
spending fixing bugs on the software I use on a daily basis (such as  koffice) 
rather than basket (which my wife uses).  

Robert

On Thursday, April 07, 2011 09:01:57 AM Scott Stubbs wrote:
> >   Like any good basket user with multiple boxes in multiple locations, I
> > religiously 'backup' my baskets, put the gzip file in a location I can
> > get to it via rsync or http to copy it to work/etc.. and then 'restore'
> > my basket store on multiple machines. It just seems to me that in this
> > day and age, I should be able to put the basket storage on a server
> > with local and remote access so I could just read/write to the network
> > basket location without having to 'backup' and 'restore' on each box I
> > have basket installed on.
> > 
> >   I don't know how difficult something like this is to implement, but
> > with fish://, sftp:// or just plain old ftp://, it seems like this
> > should be doable.
> 
> It does seem doable but it's not a straight forward task to do it
> right. Remember basket isn't set up for having multiple access at the
> same data store.
> 
> > Anybody ever looked into something like this?
> 
> Kelvie has a published basket of what he has. And recently (when I had
> a lot more time) I was looking into it. I never wrote any code but I
> was playing around with different designs on paper.
> 
> My solution feels hackish, even though I've removed the requirement to
> have it file based (so I didn't do any abstraction). But I like the
> file aspect. My next step was to discuss on here what we wanted out of
> it.
> 
> So I started with the simple common use case where people have 2
> machines connected at all times. One desktop and one laptop. Since
> they only use at a time and they are connected to the net, syncing is
> straight forward. Whether we want a centralized (at one of the 2
> machines, or a third being a server).
> 
> Next was the fact that thinking into the future, when I get a smart
> phone I'd really like to have access to my baskets. Not really huge
> idea change, since for the most part the phone is always connected
> too. It wouldn't really need a local store even. Although if you get a
> bad signal you don't have your baskets isn't ideal to me.
> 
> Next was back to the laptop. It's a laptop so I'm going to disconnect
> it sometimes. Again, local store is really needed. But then I do some
> updates on there. And then I might do a change something on the
> desktop before I resync them again. And that's where the issue comes
> in: Off line editing.
> 
> Now Kelvie has mentioned the git model. And I think that is a nice way
> of going. But I'm not sure how we'd want to implement it. If we just
> take the idea and not the code (we could use a DB as a backend), I'm
> concerned that we'll get a huge growing history. I'm not sure what
> that would do for speed and size, but perhaps we could have a cut off,
> where all things are to be at a known sync point.
> 
> Another thing is that at what level would one do the git diffs. I mean
> is it the entire basket change or would it be each property of the
> basket (mostly an issue an creation, not in modification).
> 
> And with encrypted baskets do we really want each iteration in the
> history? What if we encrypt of decrypt something.
> 
> We could try to stick with the git code as a back end, lets us use the
> files we have now. But again the encryption issue, and then merging as
> well.
> 
> Which brings me back to merging. What if there is a conflict? Do we
> give an option to do an easy merge (as in take the note with the most
> recent time) so to help out new users.
> 
> Also, I'm not sure how tide in this could be with the undo/redo aspect
> because of the encrypt/decrypt problem.
> 
> Also, what if someone wanted to use it across an office, what about
> locking the notes during edits. Now I'm now sure how serious this
> issue is, because a wiki may be more useful in that case. But maybe we
> could have a read only setting, so only one machine can change a
> basket. I'm just trying to see how flexible if we have to rewrite a
> lot.
> 
> Oh and of course we'd need to have encryption on the syncing,
> especially in the smart phone case. Oh and I'd just like to throw out
> there that QT with MySql doesn't quite have SSL. There's a patch (I
> haven't tried it) but it's been around for a while and hasn't been
> included yet.
> 
> Oh, and for a key my idea was just to sha the creation time, user, and
> host name altogether. to ensure uniqueness.
> 
> I think I wrote all my issues. Everything should be paragraph
> separated so that it's easier to discuss. When I get time to make a
> proper sql schema I'll send that out. For a timeline, I'm not thinking
> soon. A solid beta within 2 years, although that's calculated with me
> just solely writing code, which I hope won't happen.
> 
> Scott
> 
> ----------------------------------------------------------------------------
> -- Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Basket-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basket-devel

Re: [Basket-devel] How hard would enabling network/remote basket storage development be?

[Scott S. <sco...@gm...>]

>   Like any good basket user with multiple boxes in multiple locations, I
> religiously 'backup' my baskets, put the gzip file in a location I can get to it
> via rsync or http to copy it to work/etc.. and then 'restore' my basket store on
> multiple machines. It just seems to me that in this day and age, I should be
> able to put the basket storage on a server with local and remote access so I
> could just read/write to the network basket location without having to 'backup'
> and 'restore' on each box I have basket installed on.
>
>   I don't know how difficult something like this is to implement, but with
> fish://, sftp:// or just plain old ftp://, it seems like this should be doable.

It does seem doable but it's not a straight forward task to do it
right. Remember basket isn't set up for having multiple access at the
same data store.

> Anybody ever looked into something like this?

Kelvie has a published basket of what he has. And recently (when I had
a lot more time) I was looking into it. I never wrote any code but I
was playing around with different designs on paper.

My solution feels hackish, even though I've removed the requirement to
have it file based (so I didn't do any abstraction). But I like the
file aspect. My next step was to discuss on here what we wanted out of
it.

So I started with the simple common use case where people have 2
machines connected at all times. One desktop and one laptop. Since
they only use at a time and they are connected to the net, syncing is
straight forward. Whether we want a centralized (at one of the 2
machines, or a third being a server).

Next was the fact that thinking into the future, when I get a smart
phone I'd really like to have access to my baskets. Not really huge
idea change, since for the most part the phone is always connected
too. It wouldn't really need a local store even. Although if you get a
bad signal you don't have your baskets isn't ideal to me.

Next was back to the laptop. It's a laptop so I'm going to disconnect
it sometimes. Again, local store is really needed. But then I do some
updates on there. And then I might do a change something on the
desktop before I resync them again. And that's where the issue comes
in: Off line editing.

Now Kelvie has mentioned the git model. And I think that is a nice way
of going. But I'm not sure how we'd want to implement it. If we just
take the idea and not the code (we could use a DB as a backend), I'm
concerned that we'll get a huge growing history. I'm not sure what
that would do for speed and size, but perhaps we could have a cut off,
where all things are to be at a known sync point.

Another thing is that at what level would one do the git diffs. I mean
is it the entire basket change or would it be each property of the
basket (mostly an issue an creation, not in modification).

And with encrypted baskets do we really want each iteration in the
history? What if we encrypt of decrypt something.

We could try to stick with the git code as a back end, lets us use the
files we have now. But again the encryption issue, and then merging as
well.

Which brings me back to merging. What if there is a conflict? Do we
give an option to do an easy merge (as in take the note with the most
recent time) so to help out new users.

Also, I'm not sure how tide in this could be with the undo/redo aspect
because of the encrypt/decrypt problem.

Also, what if someone wanted to use it across an office, what about
locking the notes during edits. Now I'm now sure how serious this
issue is, because a wiki may be more useful in that case. But maybe we
could have a read only setting, so only one machine can change a
basket. I'm just trying to see how flexible if we have to rewrite a
lot.

Oh and of course we'd need to have encryption on the syncing,
especially in the smart phone case. Oh and I'd just like to throw out
there that QT with MySql doesn't quite have SSL. There's a patch (I
haven't tried it) but it's been around for a while and hasn't been
included yet.

Oh, and for a key my idea was just to sha the creation time, user, and
host name altogether. to ensure uniqueness.

I think I wrote all my issues. Everything should be paragraph
separated so that it's easier to discuss. When I get time to make a
proper sql schema I'll send that out. For a timeline, I'm not thinking
soon. A solid beta within 2 years, although that's calculated with me
just solely writing code, which I hope won't happen.

Scott

[Basket-devel] Don't Forget Trinity (KDE 3.5.13) and other KDE3/Qt3 distros in code decisions

[David C. R. <dra...@su...>]

Guys,

   Just dropping a note to make sure you don't forget that KDE3 is very much 
alive and Trinity is actively developed. Projects like LibreOffice, who in the 
past have disabled many of the KDE3/Qt3 hooks, are now re-enabling the KDE3 
interfaces in the code to support Trinity and the distributions that continue to 
package KDE3 (openSUSE, etc..)

   While Trinity is moving to CMake and Qt4 for KDE3, for the time being it is 
still Qt3 based. See, eg:

   http://www.trinitydesktop.org/
   https://wiki.archlinux.org/index.php/Trinity

   So if you run into a situation in the code where you're thinking "should we 
just gut this Qt3 stuff?", please remember that there are a number of active 
projects and distributions that continue to rely on basket working on Qt3.

   You might already know all of this, but I thought I would drop a line to make 
sure :p

   Keep up the great work!

   And on the window thread/patches, I think that after basket2 settles, it will 
be worth looking at developing a redistributable for XP-7. I'm not on windows 
much except for accounting and tax, but when I'm there, I always end up thinking 
"damn, it would sure be nice to have my baskets here."  Who knows -- could be 
the next killer app :)

-- 
David C. Rankin, J.D.,P.E.

[Basket-devel] How hard would enabling network/remote basket storage development be?

[David C. R. <dra...@su...>]

Guys,

   Like any good basket user with multiple boxes in multiple locations, I 
religiously 'backup' my baskets, put the gzip file in a location I can get to it 
via rsync or http to copy it to work/etc.. and then 'restore' my basket store on 
multiple machines. It just seems to me that in this day and age, I should be 
able to put the basket storage on a server with local and remote access so I 
could just read/write to the network basket location without having to 'backup' 
and 'restore' on each box I have basket installed on.

   I don't know how difficult something like this is to implement, but with 
fish://, sftp:// or just plain old ftp://, it seems like this should be doable. 
Anybody ever looked into something like this?

-- 
David C. Rankin, J.D.,P.E.

Re: [Basket-devel] A patch to support indent list and list type

[Matt R. <ma...@kd...>]

On Mon, Feb 28, 2011 at 5:43 AM, F H <bb...@gm...> wrote:
> Hi there,
>
> Although basket has the function "transform lines start with * or - to
> lists",
> the support for list editing is not as good as kjots, which can let user
> choose
> different list type. I have done some work to make the list editing function
> more effective.
> The attached patch is against basket-1.81, on top of kde4.6/qt4.7.
> Please review and consider the possibility to add such a support.
>
> Regards,
>
> Feng
>

Can you either post a merge request on Gitorious for the Basket
project or send this again to the list using git-format-patch?

Thanks,
Matt

[Basket-devel] A patch to support indent list and list type

[F H <bb...@gm...>]

Hi there,

Although basket has the function "transform lines start with * or - to
lists",
the support for list editing is not as good as kjots, which can let user
choose
different list type. I have done some work to make the list editing function

more effective.
The attached patch is against basket-1.81, on top of kde4.6/qt4.7.
Please review and consider the possibility to add such a support.

Regards,

Feng

Re: [Basket-devel] Windows port

[Lionel P. <lio...@gm...>]

Hi

2011/2/15 Matt Rogers <ma...@kd...>

> Hi Lionel,
>
> Do these patches still apply to the most up to date version of Basket,
> which is now hosted at Gitorious? http://gitorious.org/basket


Some of these patches were no longer necessary in this version of Basket.
I just have to comment the LC_MESSAGES and the crasshandler's functions
(which uses fork, getppid, ...).



> If so, please either send them to the mailing list via
> git-format-patch or post a merge request on Gitorious and I will look
> at merging them before the 2.0 release.
>

I think the comment of the crasshandler code is brutal and shouldn't be
integrated like that.
Nevertheless I will post a patch.

After one week, Basket is pretty unstable on windows XP (lot of crashes when
you move notes or change fonts size) and stable on windows Seven (do not ask
me why, I do the same installation both sides...).

Lionel