clipmap 1.6 max-texts-in-history vs max-menu-items?

[Sylvain Viart]

Hi Andre,

Thanks for your reply.

I'm not at all skilled for GUI yet.

As I was mostly hacking the history.c I met max-menu-items soon enough, 
and it was my bound to keep the behavior of rotating item it the 
history. So I reused this limit to set the size of my indexes too. 
Remember that I don't save item to disk (which is still available of 
course)  so I disable it via the visual settings GUI.

> max-texts-in-history that I think is about the number of items not bytes.
Yes max-texts-in-history is in fact the total length of items the 
history in memory (items size in bytes doesn't matter), where the list 
was truncated in _clipman_history_add_item().
This was including image too, image are counted as part to the 
max-texts-in-history.

I figured this one correctly, and I refactored all that code with my new 
data structure (double linked list + indexes).
With my new understanding of history save, I realize now, that the 
truncate was to handle resizing (in memory). I did it differently 
because of the indexes.
That's why I want to play with the history size value: max-texts-in-history

Now that I'm testing to enlarge and shrink my new implementation of the 
history in memory, it confuses me because the visual settings in clipman 
1.6 history tab, is all linked to the "Remember history" switch. Which 
is not what the code do with most of the values in the history tab:

- Reorder history items
- Reverse history order
- Ignore mouses selection
- Size of the history:

Are all used at runtime with or without saving the history to the disk, 
at least in history.c.

So may be my question becomes:

How do I break the GUI link of the "Remember history" switch and the 
greyed of gtk items on the history tab?
I would like to extract "Size of the history:" from the greyed behavior.

I saw that settings-dialog.ui was edited by glade, so I installed glade 
+ ui related stuff, I opened the .ui file and find the history tab.
I need to learn glade I think before, because I'm unable to insert an 
new gtkblock to just hold "Size of the history:" outside of the actual bloc.



In the mean time in order to test my code on resize I will add an new 
dbus method for that, because I handle that part pretty well now. It 
wont skill up my GUI knowledge but would be faster to put in place for 
me. 😉

I will also deep into the on disk history saving code to figure out how 
its behavior depend of such settings.

Regards,
Sylvain.

On 01/10/2021 00:11, andre at andreldm.com wrote:
> Hi Sylvain,
> As the original author doesn't hang around anymore, I think Simon is 
> the current maintainer, in any case the source code is the best reference.
>
> I think your understanding of max-menu-items is correct, just to be 
> sure, only max-texts-in-history that I think is about the number of 
> items not bytes. Also notice in _clipman_history_add_item that it is 
> used to truncated the in-memory list of all items, including images. 
> With regards to writing to disk, yes the items history is 
> persisted/loaded if "save-on-quit" is enabled.
>
> Well, I don't know how this impacts your implementation, but I hope 
> this helps.
>
> Cheers,
> Andre Miranda
>
> Sep 29, 2021, 03:33 by sylvain at opensource-expert.com:
>
>     Hi,
>
>     I'm trying to figure out the purpose of max-menu-items vs the
>     max-texts-in-history?
>
>     I'm modifying the code of clipman to handle Secure Item, this fork
>     https://gitlab.xfce.org/Sylvain/xfce4-clipman-plugin
>     <https://gitlab.xfce.org/Sylvain/xfce4-clipman-plugin>
>     I'm planing to submit a merge request for future version of
>     clipman, as my use of the PoC is satisfying.
>
>     So during my journey in the code, it brings me to extensively
>     modifying the way items are stored in memory, still not altering
>     the existing behavior.
>     I disabled saving history to disk which is obviously not
>     compatible with secret non-disclosure.
>
>     So the memory data structure in my fork has been changed to a
>     GList double linked list + I'm crafting a circular Indexes array
>     to handle my
>     newly introduced index / ID on the stored item. So they can be
>     delete any item from history with an external cli by index:
>     ./clipman_cli.sh del 12
>
>     The goal here was to avoid secret disclosure.
>
>     I decided to keep indexes in a circular buffer of the same size of
>     the history (max-texts-in-history).
>     The indexes are kept to low ID values because I use them in the
>     preview of Secure Item: "🔐 SECURE %2d *********", item->id
>     My history size in memory is generally of 40 or 50 items, and I
>     generally handle at most 4 or 5 Secure Item in the history at the
>     same time.
>     Some Secure Item are ephemeral so are going out quite quickly.
>     Keeping ID low also helps human to figure out which secret is the
>     one hidden in the history.
>
>     I'm actually finalizing my circular buffer code and handling
>     history size change enlarge / shrink the history.
>
>     But I'm discovering the distinct behavior or those two max values:
>     max-texts-in-history  / max-menu-items
>
>     To what I understand:
>
>       * max-menu-items is a visual limitation in the popup menu
>       * max-texts-in-history is the actual history size in memory (may
>         be also on disk, I didn't explore this part, as it was not
>         involved in my changes)
>
>
>     in clipman 1.6 the max-texts-in-history is set with this visual
>     interface:
>
>
>
>     Which is greyed as I disabled it in my use case.
>
>     So what is exactly the purpose of max-texts-in-history?
>     Should I use this value for my in memory history size or should I
>     use a different size matching max-menu-items?
>
>     Regards,
>     Sylvain.
>
-- 
Sylvain Viart - GNU/Linux Sysadmin/Developer/DevOps - France

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20211001/71d0d87b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jljmafllmnoaabdh.png
Type: image/png
Size: 21241 bytes
Desc: not available
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20211001/71d0d87b/attachment-0001.png>