Mudlet features and API requests

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Mudlet features and API requests

Post by Vadi »

Use <br> in a label.

azure_glass
Posts: 97
Joined: Wed Jul 25, 2012 12:35 pm

Re: Mudlet features and API requests

Post by azure_glass »

How to do it? Example please :)
English is not my native language. If you don't understand what im writing ask. :)
Ubuntu 17.04, Mudlet 3.1

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Mudlet features and API requests

Post by Vadi »

testlabel:echo("one line<br>another line")

tarkenton
Posts: 30
Joined: Thu Feb 07, 2013 7:33 am

Re: Mudlet features and API requests

Post by tarkenton »

Haven't gone digging, as this was a toilet thought. Is there any way to put the notes functionality into a label/miniconsole? If not, that's something I and others would find handy since it would allow for a scratchpad to easily be implemented to store info people want to scribble down or see at a glance that is really changeable.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Mudlet features and API requests

Post by SlySven »

<aside>I hope you made sure you wash your hands after...!</aside> The data is stored in the "notes.txt" file in the root of the profile's directory tree so you could always read and write it via lua file handling code stuff - though it is stored as a UTF-8 file. A quick check did reveal that the reader code {in the C++ method dlgNotepad::restore()} did not close the QFile that it creates to read in the contents - and the code that writes out the data when you close the "notes" window will overwrite the existing file; so if you are going to fiddle with the file yourself you want to tell the user when it is safe for them to have the "notes" window open (NOT while you are changing the file).

Mind you, the notes functionality is already there "to store info people want to scribble down or see at a glance that is really changeable" - just not one that can be customised to fit into a scripted/customisable part of a GUI - or is that what you want?

tarkenton
Posts: 30
Joined: Thu Feb 07, 2013 7:33 am

Re: Mudlet features and API requests

Post by tarkenton »

Fitting into a GUI is exactly what I'm looking for. Figured why recode if the functionality is already there. Is no big deal, I can write a simple, terribly optimized scratch pad. But having the user able to click on a GUI window, and just write something, would be nice instead of aliases and the like.

EulersIdentity
Posts: 27
Joined: Fri Jun 26, 2015 8:52 am

Re: Mudlet features and API requests

Post by EulersIdentity »

[ ALERT ] - Socket got disconnected.
English grammar dictates that this should be "Socket was disconnected."

On a more serious note I would love an option in the settings menu to set the location of the profiles directory. I know that things like the symlink workaround exist, but this seems like overkill if its possible to just have Mudlet look for files in a different location. I travel a lot right now and it would be really awesome if all I had to do to use Mudlet were to pop in a flash drive and open the executable.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Mudlet features and API requests

Post by SlySven »

I did a quick check in the source and found the equivalent of QDir::homeDir() + "/.config/mudlet/profiles/" is used in lots {where lots is significantly more than ten} of places! From a coding point of view I agree that perhaps the "profiles" directory might usefully be a variable - though extending this to further up the directory structure for ALL of Mudlet's stuff could give us a chicken and egg situation where the location that stores the data would be stored in a file (the Mudlet main "QSetting" file mudlet.ini) which needs to be readable to FIND the location before you can read from it...! :P

EulersIdentity
Posts: 27
Joined: Fri Jun 26, 2015 8:52 am

Re: Mudlet features and API requests

Post by EulersIdentity »

I'm speaking from a position of ignorance, so sorry if this is nonsense, but wouldn't it be best to put the location of the settings files as early as possible in the hierarchy? Any time I've coded something that relies on a configuration file to determine its behavior, I've put that file in the same directory (or sub-directory) as the executable and then had the program read settings from the file as early as I could. I also haven't written anything terribly large, so I may be misunderstanding the problem.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Mudlet features and API requests

Post by SlySven »

That doesn't always apply for OS specific file configuration locations - and it also depends on whether the settings are for a particular user or for the application's use independent of who is currently running it {of course if more than one person is using it on the same system simultaneously that also makes some things more complex} :wink:

As it happens we currently assume that the Mudlet application is configured for each user independently of any other - so the use of a sub-directory of the almost hidden ~/.config/ directory is the right thing for *nix environments, but I'm not quite so clear on how things are for other platforms...

Post Reply