Jump to content

OpenCore Configurator

notiflux

By notiflux,
in OpenCore

 Share
76 posts in this topic

Recommended Posts

notiflux
notiflux
Posted
  • Author
Posted (edited)

@Andrey1970 thanks for the heads up. I did not expect you to consider my app when it comes to config changes. I check the docs directory on the OpenCorePkg repo almost daily and I did my best to build OCC in such a way that it's easy to account for changes to the spec

 

@ricoc90 honestly I don't like when applications behave like that, so I don't think I will be changing that. I've just accustomed to hitting cmd+q to quit an app

Edited by notiflux
  • Like 2
Link to comment
Share on other sites
Rocky12
Rocky12
Posted
Posted
3 minutes ago, notiflux said:

@Andrey1970 thanks for the heads up. I did not expect you to consider my app when it comes to config changes. I check the docs directory on the OpenCorePkg repo almost daily and I did my best to build OCC in such a way that it's easy to account for changes to the spec

heads up man thanks for your great work :thumbsup_anim:

  • Like 1
Link to comment
Share on other sites
vit9696
vit9696
Posted
Posted

While @Andrey1970 is right that we do not believe automatic tools can help people improve their experience, and thus are generally anticipate them, I do not believe we can stop people from writing them, and thus will try to be as constructive as possible to avoid extra harm from any side.

 

OpenCore Configurator is an open source application and for this very reason, despite our personal views and no official recommendations, we will try to provide some help at the very least. Substantial differences in our preferences will not help much the process anyway.

 

Regarding configuration changes, starting from 0.0.1 release we have version reporting (exposed through NVRAM). We demand this to be verified by configuration app to ensure compatibility (this is stated in the docs).

— For the released version the warning should appear when the app is unaware of the version used.

— For an unreleased version the warning should always appear. 

— For no version present another warning should appear.

 

We do not care much whether the user decides to continue as long as he is informed about a potential incompatibility. We believe it is very important for the user to be aware of the problem if he still decides to use a configuration app. And the fact that every release has its documentation fixed makes it possible for a configuration app to be compatible with released versions at least in theory.

 

Additionally to that I recently added differential documentation, showing changes between the configurations [1] across the releases. The file will be bundled with the release file, and should help everyone update accordingly to the latest release.

 

Last but not least, while I cannot promise it, but we will try to find some resources to conduct a basic validation process to give recommendations in regards to decisions taken, which we consider to be wrong or improper. Closer to a more stable release of course. For example, recently we discovered that most third party tools reformat and reorder plist files, making their changes hard to discover [2]. If OpenCore Configurator is affected, we hope this is fixed.

 

Thanks for the hard work, and peace :)

 

[1] https://github.com/acidanthera/OpenCorePkg/tree/master/Docs/Differences

[2] https://github.com/corpnewt/ProperTree/issues/5

  • Like 7
Link to comment
Share on other sites
notiflux
notiflux
Posted
  • Author
Posted

@vit9696 thanks a lot for the info. I will implement the version checks tomorrow.

 

About the restructuring/ordering of the config: afaik OCC does not reorder any entries it isn't supposed to, I will check that thoroughly tomorrow though, since swift dictionaries like throwing values around. It does however change the format slightly, for example it saves data like this  

<data>
T3BlbkNvcmUK
</data>

Instead of this  

<data>T3BlbkNvcmUK</data>

This should not affect OC itself, but indeed does make comparison more difficult when looking at the plist in raw text. However I did not find a way to prevent this from happening, this seems to be the way plists are formatted when writing an NSDictionary to a file. I will investigate this further to see if I can somehow manage to make this work, if nothing else I'll manually strip the newlines after the file was written. 

 

I'm sure the differential documentation will be a huge help for parsing configs of different versions, since atm OCC can only reliably parse the current version.

 

If you have any more suggestions/changes you want to be made, just let me know

 

Thanks again and cheers :)

  • Like 2
Link to comment
Share on other sites
Guest ricoc90
Guest ricoc90
Posted
Posted
12 hours ago, notiflux said:

 

@ricoc90 honestly I don't like when applications behave like that, so I don't think I will be changing that. I've just accustomed to hitting cmd+q to quit an app

 

Well, personally I don't see the point of having the app stay open if all of its windows are closed, since then you'll have a dock icon with no actual function. 


Anyway, the decision is yours :lol:
 

Link to comment
Share on other sites
notiflux
notiflux
Posted
  • Author
Posted

@vit9696 I already found a workaround for that which is similar to what CorpNewt did on ProperTree. I just need to make sure that it doesn't reorder things for all subdicts. I already have all the code to do this but I will greatly need to change the structure of my open handler functions, so that will take some more time

 

@iCanaro You don't have any apfs volumes on your High Sierra install, do you?

I currently can't simulate such an environment, could you please run this command in terminal: 

diskutil apfs list -plist > ~/apfs.plist

and upload the resulting file from your home directory?

Link to comment
Share on other sites
iCanaro
iCanaro
Posted
Posted

High Sierra HFS+ hack 5 signature --> OK
 

High Sierra HFS+ hack 1 signature --> OK

 

High Sierra HFS+ hacK 2 signature --> crash just instantly at launch

I think that the problem is related to this current configuration of the hack

Link to comment
Share on other sites
apfelnico
apfelnico
Posted
Posted
On 5/10/2019 at 12:05 AM, notiflux said:

honestly I don't like when applications behave like that, so I don't think I will be changing that. I've just accustomed to hitting cmd+q to quit an app

 

That's right. Everything else is Windows. There is a difference between "close document" and "close application".

Link to comment
Share on other sites
notiflux
notiflux
Posted
  • Author
Posted (edited)

@Andrey1970 We're actually restructuring the UI under the hood, so when that's done, we'll add constraints to everything to allow resizing

 

@ALL here's a new build, since I noticed that the last one wouldn't allow you to select any other section.

-deleted-

 

Edited by notiflux
  • Thanks 2
Link to comment
Share on other sites
  • 3 weeks later...
vector sigma
vector sigma
Posted
Posted (edited)
On 5/10/2019 at 1:04 AM, notiflux said:

@vit9696 thanks a lot for the info. I will implement the version checks tomorrow.

 

About the restructuring/ordering of the config: afaik OCC does not reorder any entries it isn't supposed to, I will check that thoroughly tomorrow though, since swift dictionaries like throwing values around. It does however change the format slightly, for example it saves data like this  


<data>
T3BlbkNvcmUK
</data>

Instead of this  


<data>T3BlbkNvcmUK</data>

This should not affect OC itself, but indeed does make comparison more difficult when looking at the plist in raw text. However I did not find a way to prevent this from happening, this seems to be the way plists are formatted when writing an NSDictionary to a file. I will investigate this further to see if I can somehow manage to make this work, if nothing else I'll manually strip the newlines after the file was written. 

 

I'm sure the differential documentation will be a huge help for parsing configs of different versions, since atm OCC can only reliably parse the current version.

 

If you have any more suggestions/changes you want to be made, just let me know

 

Thanks again and cheers :)

It is because NSDictionary doesn't keep the order of key-value pairs, only on arrays. For that you have to write your own xml parser to both read and write a plist, i.e all that with out using NSDictionary. Anyway this is not a bug. About data tag with blank spaces and line feeds, imho is a bug from Open Core since the parser should at least remove them to keep a clean base 64 string, and in fact he already try to skeep spaces: 

RETURN_STATUS
EFIAPI
OcBase64Decode (
  IN     CONST CHAR8  *EncodedData,
  IN     UINTN        EncodedLength,
     OUT UINT8        *DecodedData,
  IN OUT UINTN        *DecodedLength
  )
{
  CONST CHAR8 *End = EncodedData + EncodedLength;
  CHAR8 Iter = 0;
  UINT32 Buf = 0;
  UINTN Len = 0;
  
  while (EncodedData < End) {
    UINT8 C = D[(UINT8)(*EncodedData++)];
    
    switch (C) {
      case WHITESPACE:
        continue;       /* skip whitespace */ ----> do the same for '\n' and '\r'

but not '\n' nor '\r', but it should. 

..as already written by someone: 

//
// Additional modifications include permitting tabulation and other whitespace
// characters to appear in the encoded data. The intention of those is to support
// Base64 data from property lists.
//

.. because that is normal. looking at any kexts in SLE, data tag are always formatted with '\n, so this parser needs to be fixed.

Edited by vector sigma
Link to comment
Share on other sites
  • 2 weeks later...
glasgood
glasgood
Posted
Posted (edited)

Hi @notiflux

 

I appreciate and applaud your time and commitment developing the OpenCore Configurator, it looks good! but, I tried using your application attached here on your post but it randomly quits unexpectedly. Do you have an updated version ?

 

I have just discovered your your latest version alpha18 . All good! thanks.

Edited by glasgood
update
  • Like 1
Link to comment
Share on other sites
  • 4 weeks later...
 Share
Go to topic listing
×
×
  • Create New...