Re: I've just killed two issues

[Matt Wilkie]

Whoa. Edward, the strength of your reaction seems out of proportion.

matt

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/f4d8aedc-3745-4cb1-ac3b-6321f7a8235e%40googlegroups.com.

Chris: cause of outline artifact?

[Matt Wilkie]

Hi Chris, i saw this in passing and wonder if it might be the same thing
you've been running into with the theme weird outline in outline thing.

"*11) Set outline: none; when styling inputs and buttons* or they will get
an outline like the below when clicked/interacted with:

"
https://dev.to/aduranil/53-learnings-from-writing-a-multiplayer-strategy-game-3ijd

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CANGB9XTAbODy2Kj8ozOGnPab8GKVu1K5L0ToSyoZ2-Wo_5C%2Bow%40mail.gmail.com.

Re: I've just killed two issues

[Edward K. Ream]

On Sat, Aug 24, 2019 at 8:54 AM vitalije  wrote:

IMHO the real problem is the way Leo handles settings at the moment. I have
> suggested several times in the past to change this.
>

I do not at all agree with this proposal. First, I'll make specific
comments, line by line. Later, I'll discuss what I think Leo's future
project leaders would be better off thinking about.

The way I see it is this. Leo handles settings using the very same
> functionality that is used to handle its primary data - outlines.
>

Having setting be outlines has many advantages, including the various
@button scripts in leoSettings.leo.


> One might think it was a clever idea that saved some coding.
>

It's not just a clever idea.  The effect on coding is, from a design point
of view, irrelevant.  The question we must ask, first, is whether such
settings benefit users.

But if we honestly and without prejudices, look at the result of this idea,
> we can see that it caused numerous complications in several other parts of
> Leo. Initialization code is an excellent example.
>

That may be true, but there is no way I would allow major changes in
settings now.  Doing so would unnecessary inconvenience Leo's users.

But there is much more examples. One of the most extreme I can remember is
> that there is a call to c.endEditing very early before any gui element has
> any chance of being created.
>

Imo, c.endEditing does something reasonable, regardless of the
behind-the-scenes complications.

By the way this call is spread throughout the code base, contaminating and
> entangling all Leo's modules. I am not very convinced that it is still
> necessary because there had been many changes since it was introduced. It
> would be good to look how to eliminate the need for this call. But this
> should go to another topic.
>

I agree. This belongs a separate discussion. However, as I note below,
Leo's devs have much more important things to worry about.

Let's continue with the way Leo handles settings. Let's first split this
> idea in two parts:
>
>1. editing settings as an ordinary outline
>2. loading settings from the outline
>
> The two parts are not necessarily bound to one another. They can be
> changed separately without too much trouble. While I am not very interested
> in changing the first, the second one IMHO should be changed in order to
> simplify other parts of Leo, and I am pretty sure the simplifications would
> be significant.
>

I am definitely *not* going to change the user's view of settings.  We
might consider adding to settings outlines, but I have no interest in doing
so.

If we ask users both newbies and seasoned are they satisfied with the way
> Leo handles settings, I guess we would find many more unsatisfied users
> than the satisfied ones.
>

Maybe.  I don't know any way to do a valid survey.

I remember loosing many hours on more than one occasion while trying to
> solve some settings issue. I am afraid of touching any settings because of
> these bad memories.
>

This section
 in
Leo's docs says:

QQQ
This search order offers almost too much flexibility. This can be
confusing, even for power users. It’s important to choose the “simplest
configuration scheme that could possibly work”. Something like:

- Use a single leoSettings.leo file for installation-wide defaults.
- Use a single myLeoSettings.leo files for personal defaults.
- Use local settings sparingly.
QQQ

Imo, this scheme should work for most users.  Leo now has several tools
that allow users to see where settings are coming from.

Many things are impossible or prohibited because of this. There is no way
> user can load and unload plugins without restart. Python is dynamic
> language and there should be no problem to allow this.
>

The problems with unloading plugins do not involve settings.  Plugins can
modify many aspects of Leo.  Undoing such general actions can be difficult
to impossible.

LeoPluginsController.unloadOnePlugin is supposed to unload a plugin.  How
well it works is another matter. The issues are similar to Python's
imp.reload.


> In almost all other editors plugins are downloaded from the internet,
> installed and switched on and off with the single click. Leo users can't
> possibly dream about such a feature mainly because of the way Leo handles
> its settings.
>

Again, I disagree.


> Switching the theme is impossible without restart.
>

Maybe, but again Leo's settings really are not the issue.


> *What can we do about it?*
>
> After editing settings in the myLeoSettings.leo or any other settings
> outline, user should invoke a command to save settings. This command can be
> executed automatically on each save. This command would read settings from
> the outline and build settings dict as it is now done during the startup
> code.
>

Leo pretty much works this way now.

The result set of settings can be stored in g.app.db for the next run.
> During the 

Re: #1289 (Global docks) is ready for testing

[Matt Wilkie]

On open I see a Leo window with several internal panels like I'm used to 
(Outline, Body, Tabs, Render) and 4 new brightly coloured panels (Test1, 
Test2,...).

The 4 test panels can be snapped off the main Leo window using min/max icon 
at top right by [x] and float independently anywhere on my desktop. 

The floats can also be stacked all into the same panel, but only as a 
component of the main Leo window. They can't be stacked when in Float mode. 
Neither can the whole stack be floated. When floating r-click to show other 
panels doesn't work, that can only be done in main Leo window.

Oh thats interesting: [Body] and [Tabs] can be floated the same as [TestN] 
but [Render] cannot (maybe this isn't new). The main Leo window is always 
underneath the floats (not necessarily a bad thing).

I am not able to add any of the standard panels into a test panel, e.g. I 
can't move [Render] to [Test2]. Any new .leo files I open go to the main 
Leo window and not a Test. 



-matt

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/1a58a572-3715-422b-a4d5-8325605ad470%40googlegroups.com.

Re: best practice for managing calendar events

[Matt Wilkie]

Have a look at todo.py plugin. I think it's enabled by default, see [Task] 
tab next to [Nav], [Tags] etc. (Disclaimer I haven't used it)

matt

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/83b96b14-25f3-4080-b956-84135e284ec1%40googlegroups.com.

#1289 (Global docks) is ready for testing

[Edward K. Ream]

The first comment of #1289 
 contains details. 
The highlights:

- To test, switch to the "gui" branch and use the --global-docks 
command-line option.

- The Outlines (plural) dock is a global dock.
  For testing only, the code creates four global docks.
  Right-click the title area any global dock to see the other global docks.

- Each Outline (singular) dock is a local dock, containing all other local 
docks.
  Right click the title area of any local dock to see the other local docks.


*Summary*

Remarkably few changes had to be made to the code to make this all happen. 
I don't expect serious bugs.

I am mainly concerned that people like Chris can use their existing layouts 
in the new scheme.

Please report any problems immediately.  The new code should be safe to 
merge into devel, because the gui branch should work *exactly* like the 
devel branch when --global-docks is off.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8adaa291-65a1-4c23-91c4-746b2c51e5d8%40googlegroups.com.

Re: I've just killed two issues

[Brian Theado]

Vitalije,

On Mon, Aug 26, 2019 at 3:42 AM vitalije  wrote:

> Do you envision distributing the leoSettings.leo derived database with leo
>> itself? Or do you have something else in mind? I was wondering how that
>> first database of settings would be available at the time of leo first use.
>>
>
> Leo defaults contained in leoSettings.leo should be distributed in their
> "pre-compiled" form. For example it could be one python module containing
> one big tuple of tuples representing the initial content of db. On start if
> this db doesn't contain table settings, table will be created and populated
> with the default values from this python module. This action is executed
> only once and it takes negligible time. For new users the result would be
> exactly the same as if they installed Leo and run it for the first time
> before they created myLeoSettings.leo.
>

Sounds reasonable and it would probably also be possible to have a
"compile-settings" command line option for leo which could be used in place
of the "open myLeoSettings.leo and save it again" you mentioned.

About 10 years ago I worked on some server software we wrote in C. The
configuration was controlled via a complicated set of sqlite tables. They
were complicated because it was a structure which made it easier for the
end-user configuration UI. We decided to have the C code initialization
structure be as simple as possible. We kept the complexity of transforming
the complicated structure to the simple structure far away from the
harder-to-change C code. This decision was very helpful. It resulted in
fewer changes to the C startup code and the changes we couldn't avoid were
made on simpler code. The simpler structure would have been onerous for the
user to construct, but the data transformation took care of hiding that
difficulty from the user. Having the transformation separate from the
server code, it also made it much easier to troubleshoot.

I see the leo situation as somewhat analogous. The settings-in-outlines is
easier for the user to deal with just like the complicated sqlite tables
were easier for our configuration users, and the settings db you propose is
easier for the code to deal with just as our simplified C structure was for
our server software. Data transformations can be useful!

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAO5X8CzK4nhaK61%3DgzPnaMDmsH4dFWO%3DrbDX91iuOguqSvx0VQ%40mail.gmail.com.

Re: I've just killed two issues

[vitalije]

>
> Do you envision distributing the leoSettings.leo derived database with leo 
> itself? Or do you have something else in mind? I was wondering how that 
> first database of settings would be available at the time of leo first use.
>

Leo defaults contained in leoSettings.leo should be distributed in their 
"pre-compiled" form. For example it could be one python module containing 
one big tuple of tuples representing the initial content of db. On start if 
this db doesn't contain table settings, table will be created and populated 
with the default values from this python module. This action is executed 
only once and it takes negligible time. For new users the result would be 
exactly the same as if they installed Leo and run it for the first time 
before they created myLeoSettings.leo.

For users that have already created myLeoSettings.leo, we can allow some 
grace time period when Leo starts as usual (reading all settings files), 
and after start Leo can just store all processed and collected settings in 
the settings db. On the next run Leo would use db.

Then in the next phase when all users have their settings db created, we 
can start cleaning the startup code and remove unnecessary code parts. 

That should cover most of the users. Users who install only release 
editions, will have in the next release both startup routes (one reading 
leo settings files, and one using settings db). On the first run the old 
startup route will read and collect all settings and after startup those 
settings are written to settings db. On every next run when settings db is 
present, Leo will use the second route. In the next release first route can 
be removed.

For users who use git version, the situation will be similar only they 
would sooner get their settings db created.

Almost none of the Leo users would have to do anything special to switch to 
new settings code. The only case when some action is required from users is 
if they switch from the current release to the release when startup code 
has been cleaned and Leo will miss their myLeoSettings.leo. But in this 
case they would simply solve the issue by opening their myLeoSettings.leo 
and saving it.

Otherwise, as I'm conceiving of it, this scheme would then also need a 
> mechanism to compare the saved state with the settings .leo files, 
>

Theoretically speaking yes. But in the reality g.app.db is never changed 
outside Leo (or at least we can say it is not supposed to be changed 
outside Leo). If someone changes g.app.db outside Leo, well I don't think 
that Leo developers should be concerned at all. If someone deletes g.app.db 
(sometimes it is suggested to do so), user should afterwards open 
myLeoSettings.leo and save it again, and db will be fully recreated.

The worse possible case that can happen is that on the next run Leo use 
only default settings ignoring myLeoSettings.leo, and in this case user 
just need to open myLeoSettings.leo and save it.

Vitalije

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/348984f1-9e84-4367-950d-5fb594526eb3%40googlegroups.com.

best practice for managing calendar events

[Austin(Xu) Wang]

Hello Leonine,

I have a number of projects in my leo file, some of the projects have 
events.  For example:

ProjectA -> Meeting With Donald (Next Monday 10:00)
ProjectB -> Meeting with Steve(6th Sept 15:30)


Is there a way I can see a list of events for all the projects?

BR,Austin

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d9f7e541-7c5a-429e-8161-f58c23b918e6%40googlegroups.com.